车站评论的内容都是自己一条条写的，有一部分来自向朋友解释case背景后、朋友帮忙撰写或提供素材的，另一部分则是自己以最大限度的代入感和同理心去编写的。

　　在开始内容卡片的设计前，需要「编」很多故事，这期间就会不由自主地开始思考：这类评论，一般会写多少字?文字在卡片中全部铺出还是按固定长度截断?字数的变化会对卡片设计产生怎样的影响?最多折几行?行高多少?字数很少时会不会显得奇怪?图片尺寸怎样去适应字数变化?

　　最终，故事文字最大长度确定为150，不同场景的卡片分别选用截断和完整铺出的处理方式，都是在这一系列思考后确定的答案，每个小问题具体的分析就不在这里展开了。

　　围绕文字的设计，再聊一个问题——故事是否要求填写标题?

　　起初设计的时候，可能不由自主地想画一个标题上去。相比铺出长度不固定的内容，有标题确实某种意义上对设计更加有利。

　　但自己和朋友在撰写的时候都不由自主地觉得标题很累赘，在设计时都如此，更何况真实用户使用的时候。且对于全文长度仅有150的故事内容，标题存在的价值很难说得圆。

　　所以，后续设计中就取消了标题的设置，改为直接透具体内容。如果没有代入用户视角去尝试编写内容的过程，很大概率不会想得这么深入。

　　对目标用户群体而言，是否需要提供个性签名功能?曾几何时一大票APP无论什么类型，都照搬QQ的个性签名系统，结果填写率惨不忍睹，设计的签名位要开了天窗。因此，这点是需要在稿子中“编”签名时同时思考的一个问题。

　　考虑到产品受众多是内心细腻、渴望个性化表达的群体，而自己和朋友「编」签名的过程也非常流畅，结果呈现出来也和产品调性比较吻合，所以最终采用了有签名的方案。

　　说到底，个人一直觉得，了解一个产品的用户调性是非常重要的，是指导自己设计思考的一个股没有实感却又不可忽视的软性力量，persona不是走过场，而是在设计中时刻要去思考的问题。

　　同样是出自网易、以评论系统闻名的两个产品，网易云音乐和网易新闻，用户的语言风格和评论习惯是完全不一样的，为什么云音乐的评论回复是单对单的私聊式，而网易新闻则以“楼中楼”模式诞生的各种神楼闻名遐迩，产品的很多特质并非上线前就完全想好这样设定的，而是被用户调性反向输入的结果。

　　结语

　　也许很多朋友看完的反应都是：话是这么说，可实际项目中哪有时间去这么打磨稿子里的内容，能把框架按时交付就不错了。

　　可我最真实的感受就是，我还真没感觉这道工序影响了我的效率。难道是因为当年war3练就的手速?

　　我想，最合理的解释还是因为这样的习惯已经陪伴了自己很久。也许当年第一次细究内容的不真实性、逐一改掉时，会觉得有点费工夫，但这次改掉一个点，下次在聊需求、出稿子的时候就会自然而然地在第一时间把这点考虑周全。久而久之，对内容做个简单的把关，真的没有想象的那么费时间。

　　即使项目真的十万火急到没时间在设计稿上呈现，对真实性的持续性锻炼和思考，至少能帮你时刻周全地考虑到这些可能影响设计的细节点。

　　我想，这才是对勤于思考受益终身的奖赏。