从失败中学习：谈谈设计师的成长日记( 二 )

比如，有个字段是描述，这个字段要考虑最多允许用户输入多少个字符。当显示在表格中，显示多少要截断用【……】来展示， hover显示全部。或者因为该字段特殊性，就是要完全展示，那就要考虑换行的设计。如果这个字段是在详情页展示，是否就完全展示，这都是需要斟酌的地方。
虽然这是个很小的细节，但是其实要考虑的事情很多，有时候不一定会体现在设计上面，但是设计师要自己清楚规则是什么。
NO.3 永远的伸手党
【从失败中学习：谈谈设计师的成长日记】

本文插图
设计师Jane今天要做一个动效设计，发现自己好像没有这类网站收藏，她就问了隔壁设计师John 。

本文插图
生活当中，不知道你是否会碰到这样的人，总是问你【这个怎么做】【那个网站推荐下】等等，这里想强调的不是帮助别人不好，或者说寻求别人帮助就不对。而是自己是否先查找过，当从别人那得到想要的【资讯】时，是否多做一步，保存收藏，消化吸收。
培养自己成为主动的人，付出代价学会的东西，才会变成你的东西。任何在网络上可以查到的资讯，不要问别人。你对查到答案感到怀疑，再和别人讨论，那是另一件事。
NO.4 Yes Designer !

本文插图
大家应该都有看过金凯瑞Jim Carrey的【好好先生Yes Man】，剧中男主角因为对所有人都说YES ，他遇到了一些有趣的事，也因此遇到女主角， happy ending… 但是如果设计师也这么做，这或许就不是你的happy ending了
这两个案例，我经常碰到。业务方想想加个字段，加个功能。但是问题不在于需求本身，而在于设计师对需求态度。不要对接到的需求，全盘接收，当然也不要全然否定。很多时候会发现这个需求是不合理的，或者这是伪需求。要主动挖掘需求的盲点，了解它，不要被业务方给出的解决方案迷惑，用全局视角去看待这个需求，去评估其合理性。

本文插图

尽量让需求方提供文档或原型，方便后期追溯。口述需求，容易产生误解，有文档的话需求也会更加清晰；
梳理完需求后，再拉需求方过一下需求，毕竟人与人之间的理解是有gap的。可以让需求方拉会议，技术和设计同学都需要参加，如果涉及业务，最好也拉业务一起；
这可能是一个循环的过程，也不要太纠结为什么需求方没理清楚就找你，需求有时候也需要反复推敲才完成。

工作当中总是会遇见【很好心】的一些人，他们给你提需求的时候，也同样提供的解决办法，有些时候他们提供的想法真的挺好的，眼前一亮。但是有些时候，却是【不合适的建议】，所以设计师要能分辨他们提供的建议是否适用于现在的产品，大家提出自己的观点时，都是主观的从个人的角度出发，个人的利益着手，会选择性的忽略对全局产品的影响。但是，设计师却要更全局的去看待，一个小功能点的添加有可能会影响其他的地方，如果没有全局的评估，设计的工作会让你变成【不是在挖坑的路上，就是在填坑的路上】。
NO.5 为了反驳而反驳