时间: 2021-07-30 10:14:46 人气: 3 评论: 0
本文作者将基于自己的成长经历，从不同的链路点中告诉大家一些实用的工作建议和方法，希望对大家有所启发。enjoy~
很长一段的时间里面，大家都在提倡说要做全链路设计师，就是在一个项目中，设计师你不仅仅专注在自己的视觉/交互设计中的点上，而是可以承担从用户研究 > 交互设计 > 视觉设计 > 设计走查 > 体验优化，项目从开始到结束的全部相关设计工作，这时候我们可以称自己为体验设计师，而不仅仅是交互/视觉设计师等。
体验设计师的使用场景，主要有两个：
现在问题来了，在精力有限的情况下，工作/任务属性；公司规模/方向决定，你承担着体验设计师的角色，精力被平分在整条链路的多个点上，如果你的项目/需求/任务又是非常琐碎的，例如今天做个Banner ，明天给别人的网站重新设计一下导航等，如何在周期很短任务很急，任务属性差异又很大的时候，作出价值，让自己受益，别人也关注到你的成长和进步呢？
因为工作场景和任务属性决定了，在一个项目中我既要承担 PD，用研，交互，视觉，又要承担运营的工作，从最 1 年前上面的问题困扰我很久，处理起来吃力不讨好；到 1 年后的现在，我已经找到了一些自己的方法和技巧，能做出一些自己和别人都看到的显性价值。
我想大家也许在初入职场中，也可能遇到过类似的问题吧，下面我将基于自己的成长经历，从不同的链路点中告诉大家一些实用的工作建议和方法，希望对大家有所启发。
当你接到一个需求的时候，首要任务肯定是先了解清楚项目背景和需求主要解决的问题，可是当你自己就是 PD 的时候，只能靠自己去搜集用户信息，从设计层面提升用户体验。可是从接到需求到项目交付，如果只有三天时间，那么如何从这个小需求点中做出价值呢？
（1）把所有的沟通调研内容沉淀下来
把你从用户那里了解到的信息，整理过后，用文字的方式记录和沉淀下来，最好是把需求背景，用户痛点分点描述清楚。（最好是附上和用户问答的源文件，便于后续浏览者参考）
（2）用设计模型，把相关的数据结论可视化
因为文字的浏览和阅读成本较高，短时间内项目组成员并不能快速直观感受到调研结论和重点，可视化调研结论能更明确了产品目前的核心价值点和团队成员发力点，也降低了大家的理解和阅读成本。例如用用户旅程图表现用户在不同场景下的具体痛点，便于项目相关着直观查看。
举个例子：
可视化前，整理的所有调研数据，效果如下：
1）是什么产品，用户是谁？
2）这款产品能做什么，核心竞争力是什么？
3）目前产品有啥问题，如何优化/解决？
可视化后，对调研数据整理出来，效果如下：
1） 是什么产品，用户是谁？
2）这款产品能做什么，核心竞争力是什么？
3）目前产品有啥问题，如何优化/解决？
相比可视化前后，大家肯定都**觉得可视化后的同学更专业，思考深度更佳啊；尽管都是同样的数据，但是可视化前的文字记录和沉淀效果并没有突出 UX 同学的专业价值，原因在于没有用专业的方法呈现专业视图，说不定换另外一个开发同学也能记录成这样，说不定分类比设计同学还更有逻辑性；其实，可视化的能力并不仅仅是做美图的能力，而是对体系化设计思维和专业能力的表现，面对不同工种的项目组，一定要表现出自己的专业力量。
（3）抽取通用性调研信息，进行设计赋能
把相关生涩的专业的名词记录下来，供后续的开发/项目相关的人了解查看，节约沟通成本；
或把自己做用户研究的方法和流程以及技巧等记录下来，可供团队其他成员复用。
用户研究结束后，就是具体的功能设计层面了，可是在功能设计中，又有交互层和视觉层，根据功能类型的不同，我们可以从下面几个点进行借鉴和总结：
（1）根据单个功能，考虑类似功能的通用解决方案
例如你在给一个网站重新设计一个导航，那么短期交付内，如何还能挖掘到更大的价值，下次遇到这种问题如何才能做的更好呢？而不仅仅是一个导航设设计完了就设计完了，思考也因此终止了。
其实我们可以把导航领域相关的东西都搞清楚，到底什么场景下适合什么样的导航样式，配合具体需求的使用场景，我们可以把这一类的问题搞清楚，以后都**事半功倍。
甚至可以考虑是否可以做成团队的组件库？把研究的成果给身边小伙伴复用，集体为团队带来更大的价值？
之前我的老板总觉的我不能够深度解决问题，我总以为他是觉得我对单个设计方案做的不够精致和细致，后来才逐渐明白，单个方案的精致程度和整体系统化的解决方案结合起来，才能真正做到深度解决问题，解决本质问题。
（2）抽取设计规律，总结设计方法原则和技巧
如果是单个视觉的功能点，例如平台入口的的Banner 设计等，如果不要让设计至于交付，那么我们可以对界面中的各个元素进行归类研究，不同元素放在页面中不同的位置**组合成对应的什么风格，产生什么样的点击效果等（这个需要做专业测试，比较成本较大），如果是营销类的 Banner 可以做AB测试，看流量变化；或者接到多种同类需求时，可统一组织用户进行测试（可利用眼动仪或其他等），总之就是要从一个问题中，发现一类问题的通用性，总结出一套可复用的规则，才能不让一个功能/多个功能做了就做了，价值仅停留在做了这个层面。
（3）根据同类功能，抽取和搭建页面模板，完成赋能
如果这个需求时需要一些时间，完成后，我们需要交付多个页面，那么我们是不是可以把通用性的页面抽取出来做成页面模板呢？交付给业务方/补充道团队的规范组件中去，一举两得。设计素材的总结和复用，对于自己后续的设计成本节约也比较大。
整体来说，对这种零散的需求，我们需要利用业务时间来做一个系统的整理和归类，考虑把他们串联起来，组合成一个系统，形成一个闭环，从产品的维度产生更大的价值呢？
“管中窥豹”，“以小见大”“，这让你不仅仅局限在满足业务需求中，被动交付任务；更能体现出你主动推动项目进展，发现总结问题的思考能力，更能让你从中发现主动探索的兴趣，提升自我竞争力。
项目上线后，作为设计师，如果你还要担任运营推广的角色，那么我建议你可以从以下几点，把自己的价值体现的更加深刻和直观。
（1）对常用联系人和渠道汇总沉淀
相关渠道/联系人的汇总；把你沟通申请定好的渠道联系人统一集合成一份文档，沉淀下来，给后续需对接的人使用，避免项目成员重复沟通。
（2）对相关物料进行系统化梳理和总结，统一规范，便于查找
复用性的宣传材料的尺寸，模板；每一种渠道需要的材料和具体的尺寸是多少，直接标注清楚，避免反复沟通确认和查找。
（3）数据驱动创新，保持对数据敏感，并从中发现运营机**点
规律性的发现，哪种渠道，哪种时间点最有效果，指导后续使用；什么时间投放广告获得的点击率最高，用户互动性最强，这个需要根据目标用户的工作习惯去定制和执行。
例如内网的阿里内外启动页一般是早上10：30左右点击率最高，那是因为这个时间段刚来公司的人需要查看下最新消息/需晨间的短暂休息，根据用户习惯而定。
（4）提升风险把控能力，确保投入产出比平衡
投入产出比的预估，风险预估；对每次运用活动都进行数据总结，比较预期的目标和最终的结果；总结投入产出比；逐渐培养自己对风险预估和判断的能力，更好的指导下次的运营和项目目标相对精准的设定。
最后，如果你还兼职了部分用户答疑的工作，每天**不定时和用户沟通明确他所反馈的问题，负责记录沉淀用户的问题，指派给不同的对接人解决。那么我建议你可以从以下几点对自己：
（1）摸清用户问题点的本质，努力转换成功能机**点
沟通明确这个用户的问题到底是什么，他最本质的需求是什么，要解决什么问题，弄清楚以后，针对他的本质需求，转换成一种产品的需求，如果是设计能够解决，那么就给出解决方案，持续跟进下去直到问题解决。而不是只是单纯的把问题记录下，抛给别人，然别人去解决，其实有挑战的地方，机遇也是并存的。
（2）对答疑问题进行总结归类，发现问题类型和规律，明确后续方向
总对自己负责的一段时间内的用户反馈问题，按照问题的属性进行归类，总结和分析，
按照需求/任务/缺陷，分别指派给对应的人，但是这些问题中具体问题板块的比例呢？缺陷多还是需求多？是目前的体验不好，还是功能不全，覆盖面不够呢？根据反馈的问题数据可以挖掘到更深层的含义，如果是很多关于体验点优化的，那么到底是哪一种类的体验点被反馈的最多呢？是设计层的还是技术层的呢？？？
举个例子——
对问题整理归纳前：
对问题整理归纳后：
很明显，整理归纳后的数据结论更具参考价值，不仅能找出目前产品的体验问题和后续重点优化方向，还对有限的数据信息进行更深刻的挖掘和利用，扩大其复用价值/发现做好的机**点。同时更体现了你的思考深度和专业能力。
（3）考虑如何聪明的偷懒，优化自己的工作模式，提升效率
例如前段时间在做一个移动运维工具，用户反馈的群里，很多用户总是问同一个问题，就需要一个人/多个人重复回答很多次；我就想是否可以又更省力的解决方案呢？后续我就对重复问题的通用型答案进行提取和整理，把答案输入给智能问答的机器人，把它添加到用户答疑群。
从用户的角度来说，机器人反馈问题的答案更统一，反馈也更快，用户就**觉得体验更好；从开发者的角度来说，更节约了我们重复回答问题的人力和时间，我们用这时间去做更多对产品有价值的思考。
之前看过一句话，叫做“高质量偷懒胜过低质量的勤奋和努力”，看到后还是有些震惊的，也顺便给大家分享下。
很多时候，我们总是想着去做大项目，解决大问题，其实一个产品从 0 到 1 的时候，这样的场景**比较多；可是一旦产品做起来，从 1 到 2 ，再到 3/4/5 的时候，更多时候都是在修复和调优一些细节点的体验，那么这个时候也就决定了我们的工作属性是琐碎的，连贯的，长时间去出处理不同任务/需求点的，所以如何学**从小事中做出价值的能力就显的非常重要。以上的经验和建议都是基于个人的工作经验和踩过的坑，希望对同样在经历着这些的同学有所帮助和启发。
作者：薇子-TXD技术体验团队，阿里巴巴交互设计师
本文由 @阿里TXD 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
