大家好，就上一篇文章来说，部分设计师朋友反应讲的太抽象，都是大道理，看完似懂非懂。这一期，我把在工作上面收获的一些经验和需要避免的“坑”等细节方面进行一个总结，也算是阶段性的自我沉淀。

设计经验分享

注意输出内容的规范化

输出内容的规范化是体验设计师的必备技能。无论是设计文档，还是日常的汇报材料输出，都要站在信息接收人的角度去考虑。（例如：文档撰写时，是否使用结构化思维，谈论问题的时候先说结论，需要强调的细节问题需要特殊标注等等）

图 a 和图 b 哪个对你来说接受信息的效率高？答案显而易见

转变思维

当产品设计中遇到难以解决的问题时，我们可以尝试转变思维。例如，当你接到一个需求时，在设计环节尝试了很多，发现根本没有一个合理的解决方案，这时候你便陷入了自卑和迷茫中，难道真的是自己能力不行？很多设计师都会一不小心掉进自我怀疑的陷阱。

之前工作中，有遇到一个需求，作为设计师其实用很简单的交互逻辑就可以解决问题，但是开发说平台不支持这个功能，因为平台不支持，设计师要重新更改设计方案。后期，出了很多方案，始终不满意，最终的解决方案是向上反馈，先让平台支持这个功能。

有时候设计上遇到的问题，并不一定是交互问题或是视觉问题，甚至是产品问题，而有可能是需求背后的资源配置问题，甚至是需求本身有问题。设计师要善于转变思考方向和方式，从而找到问题的根源。

敢于试错和探索

设计师在做方案的过程中，不要只执着于自己脑子里既定的方案，觉得自己的这个方案已经很好了，或已经想不出更好的了。体验设计师需要多了解竞品，分析优劣势，在设计过程中反复问自己，这个方案是最好的么，有没有更好的？对于创意设计师而言要多风格尝试，多一些颜色的搭配和多一些元素的排布样式，也许会有奇妙的“化学反应”发生。

不过究其原因，无非就是一个“懒”字，设计师要敢于克服自己的惰性，敢于探索和试错，不怕麻烦，不怕失败。好的产品和创意，都是在不断的试错和探索中产生的，这也是大牛设计师不断的成长的秘诀。

保持对齐

在团队协作的过程中，你有没有遇到这样一种情况，当某个开发或者 PM 问到你一些设计细节问题或者规范问题时，你发现并不是你负责的模块，便直接说，你去找 XXX 吧，他是负责那一块的。而当你下次遇到这个问题的时候，你不知道上次相同的问题如何处理了，再去问当事人，效率会非常低。

这个问题涉及到了一个团队协作性的问题，当团队达到一定规模的时候，为了保证团队整体协作的高效性，我们需要实时同步对齐团队的设计规范和问题细节，让每个成员都了解和知晓，并保证下次不会犯相同的错误。

为了避免这种现象，我们可以将问题提出者和相关设计师拉到一个群组里讨论，他们讨论的结果如何你便知晓，如果是团队外部同步，需要拉齐当事人、负责人和其相关成员进行同步对齐。

符合规范还是打破规范？

规范是死的，人是活的，设计应该符合规范但同时又要打破规范，在某种程度上，这是自相矛盾的。我们需要去慢慢的摸索，去寻找那一个设计的平衡点。

设计规范的创建目的是为了统一团队协作中设计的一致性，以便达到高效率的协同。但有些特殊化场景我们不能为了满足规范而把它强行规范化起来，那就我们需要结合当时的业务场景，交互视觉方面综合去处理设计样式，最后得出合理化的解决方案，也许与规范有些许差异，但是问题得到了完美的解决。

总结一句：设计的基础不能脱离规范，但设计师思维不应该被规范所束缚。

跨部门协作，规范保守定义

如果在日常工作中，遇到没有定义的规范组件，你会怎么做？相信大部分人都会说，既然没有定义，直接定义不就好了。但是如果临时定义的规范之后有些业务场景不符合怎么办，如果和其他业务线规范相冲突怎么办？

这就说到了跨部门沟通协作。当在时间紧急的场景下遇到未曾定义的规范类问题时，不用着急去定义，先要和各个设计部门规范负责人进行对齐，对相似场景类的规范问题进行沟通，有成熟的方案可以直接参考或在原规范上进行补充修改，保证定义的规范与整体规范方向偏差不会太大，同时又保证了整体设计效率。

从竞品的角度思考

在设计的过程中，我们总是在参考竞品，但是参考竞品的同时，我们需要思考竞品究竟做的好不好。如果在场景符合情况下，优秀的竞品是值得我们参考的，如果连竞品也没有更好的解决方案，我们需要思考，为什么竞品没有更好的解决方案，是不是需求本身就有问题，为什么会产生这样的现象。

如果我们深入思考问题背后的原因，找到问题的根源所在，这时我们就可以很轻松的解决此类问题，从而会有更好的方案产出。

主动沟通避免闭门造车

设计师还有一个常见的问题就是闭门造车，拿到需求后自己琢磨，遇到问题不会与他人沟通，最后造成整体项目 Delay。很多人肯定笑了，沟通谁不会？可是当你沟通的对象会给你巨大压力和负面反馈时，你的心态还会一如平常么，你还会继续沟通下去吗？

认识一个朋友，之前心态很积极，遇到问题总是寻求他人帮助，深知不懂就问。自从换了项目组后，她遇到了一个非常严厉的 Mentor，在沟通过程中，似乎遇到了一些挑战。经常得到的反馈例如：“你想清楚再跟我说吧”，“你自己再想想吧？会有办法的”，“作为设计师，你这都没了解清楚？”，“这个我没法给你建议，你自己想吧”，对于这一系列无效的反馈，每一次都打击着她的自信心，让她产生自我怀疑，不敢再去直面问题，最终得出的结论就是自己能力不行。

对于这种情况，我们需要做到以下 3 点：

1、问问题之前先思考，请求他人建议之前先展示自己的想法

这个点，我在之前的文章里提过，好的答案很多，好的问题很少，问问题的时候尽量带着思考去问，避免问出“太低级”的问题，这里我就不过多赘述。

2、对于质疑需要问清楚细节

当他人指出你的问题过于主观和抽象的时候，我们需要追问细节，到底哪里有问题？有没有好的建议和解决方法？否则你根本不知道如何去改正问题，如何明确优化方向，进而陷入新一轮的闭门造车中。

3、转变心态，不耻下问

面对质疑和批评，我们需要转变心态，别人提出问题也是在帮助我们成长。但是如果对方只提出问题，毫无根据且没有建设性意见时，那就可以认定的确在抬杠，对此我们也可以选择性忽略。

还想提到的一点就是设计师目标是解决问题，不要在如何解决问题上有太多的顾虑，放下包袱，大胆去问，没有人会瞧不起你，不耻下问总是没错的。

警惕惯性思维，多考虑使用场景

在日常工作中，往往因为一些习惯性的设计思维，而犯低级错误。比如下面这个例子

设计规范中，例如：A，规定一个 button 单独存在的样式是 primary，当两个存在的时候需要有层次区分，避免两个 primary 的出现。假如现在我们去掉「升级」这个 button，让「卸载」单独存在，那究竟是样式 B，还是样式 C。相信很多朋友因为惯性思维，认为 button 单独存在时，应该为 B 方案。而问题的答案是，我们需要考虑当前的场景，当我们不需要强调引导用户进行「卸载」操作时， button 就不能为 primary。

主动发现问题，避免按部就班

在设计过程中，有些组件或模块是之前已经通过设计评审确定的方案，但在后期的评审中出现了场景不符或有歧义等问题，这时候就需要设计师主动发现这些问题并成立专项进行推进优化，而不是在遇到这些问题的时候，归咎于之前的设计规范和设计方案。

竞品是这样做的

在产品设计过程中，我们需要注意一个思维误区，不要总是拿“竞品是这样做的”当作挡箭牌，在讨论过程中，这不是产品设计的决定性因素。那么什么时候我们参考竞品，什么时候我们需要思考更好的方式呢？答案是：如果我们的方案整体低于竞品水平且没有更好的方案时，我们需要参考竞品，也许竞品的解决方案是现阶段的最优解。

判断你的方案是否有可行性，也可以参考竞品。如果你的方案在讨论阶段，没有得到大家一致认可，且竞品也没有类似样式时，那说明你的方案多半可行性较低。

开发不能实现

在之前工作的时候，我养成了一个习惯，在设计一些复杂交互的时候，经常会询问开发的意见，看是否能实现效果，如果不能实现，往往设计师会妥协，这其实无形当中限制了设计师的思维和创意。遇到过很多设计师都在抱怨与开发的合作，最终产品上线之后，都在说其实有一些更好的效果，就是开发没法实现。当我再问你那些所谓好的效果，能展示下么？却得到了开发都没法做，我还做它干嘛？类似这样的回答。

还有一些设计师朋友在小公司（10-100人）负责一些边缘产品，每次和我抱怨产品有个人喜好，供自己发挥空间太少，开发不配合，很多功能没法实现。面对这些抱怨，我问他们有没有从自己的视觉角度做一套 Redesign 之类的，往往回答都是没有。所以说当设计师有这类思想的时候是非常危险的，看似是客观问题限制了自身，究其原因还是自己主动性的问题。

用户验收（UAT） 需要多端走查，流程要严谨

用户评价一个产品不会只看设计师输出的效果图，而是经过开发后上手体验的结果。元素的对齐，字号颜色的使用正确与否，交互的流畅度等等都会决定用户对产品的第一印象。很多设计师跟我抱怨过，开发不太配合，开发没法实现，但作为职业化设计师，你究竟有没有主动去推进 UAT（用户测试验收），还是得过且过 ？产品最终质量也侧面反映出设计师的负责程度。

在验收过程中，需要严格进行多端走查，PC 端选择 Mac 和 Win，移动端选择 IOS 和 Android 双端走查，避免只有单一走查，而造成上线事故。

总结

以上就是我入职头条后的一些沉淀和分享，也是渐渐完善职业化设计师自我修养的一个过程。希望文中提到的内容能帮到每一个渴望进步的设计师。

文章到这里就结束了，如果对本期内容有兴趣想交流的朋友不妨在评论区留言，我们共同探讨。

Powered by Froala Editor