提交需求
赛事与广告咨询合作,请填写需求表单,我们会在第一时间与您联系!
本文 3430 字,建议阅读时间 10分钟
大家好,就上一篇文章来说,部分设计师朋友反应讲的太抽象,都是大道理,看完似懂非懂。这一期,我把在工作上面收获的一些经验和需要避免的“坑”等细节方面进行一个总结,也算是阶段性的自我沉淀。
设计经验分享
注意输出内容的规范化
输出内容的规范化是体验设计师的必备技能。无论是设计文档,还是日常的汇报材料输出,都要站在信息接收人的角度去考虑。(例如:文档撰写时,是否使用结构化思维,谈论问题的时候先说结论,需要强调的细节问题需要特殊标注等等)
图 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
大牛,别默默的看了,快登录帮我点评一下吧!:)
登录 立即注册