工作反反复复如鸦片令人生厌，也会让人着迷。因为需要生活，需要一些无形成就感刺激感官。但时间长了会让人淤结，所以需要偶尔吐槽，找一个宣泄入口，以便后续接着受虐。趁着今天不加班，不加班啊（其实是没想法偷跑出来的），跑完步一泻千里的宣泄。

说好宣泄了，权当是戏谑，给生活加点料。平时讨厌读一些“高大上”的“专家文”，所以不会写一些晦涩的东西，好像也写不出。文中偶有一处的玩笑仅为玩笑，没有歧视任何职位的意思。我尊重所有待世界以温柔的人，除非你十恶不赦（我也管不着）。要是有人不尊重你们，我可以给你递砖。不喜轻拍，不打脸就跪谢。

回到正题，笔者，暂且自称为笔者吧，就职于一家出产行业类企业级软件的公司。行业类：专注于某些专业行业领域，如交通、公交等。企业级：顾名思义是给企业用的，不多啰嗦了。公司业态决定了保密性，所以文中的一切图片皆为化名。如有巧合，只能怪缘了。

（PM:产品经理 RD：开发工程师）

与民用的产品相比，这类软件就是一个特点：怎么这么复杂（笔者内心布满蜘蛛网），因为专业啊。复杂的逻辑，复杂的界面，复杂的表单......    好吧我就循着简化的产品设计流程讲讲自己的设计感想吧，只有这样我才能确保知道自己说的是什么（太复杂理不清）。自己的想法哟！笔者工作不久，见识短浅，欢迎大咖斧正。

需求阶段

案例一：需求量少，逻辑山路十八弯

说好的复杂就从这开始了，有些产品逻辑过于复杂PM写不出需求文档，只能双手双脚的比划加上涂涂画画，好像还是说不清楚。而且产品还偏专业啊，一专业就技术....     让笔者哭一会，哪有真空玻璃罩。

面对这样的产品，笔者只能和PM比翼双飞了。在这种情况下笔者只能与PM彻夜促膝长谈，尽可能多知道他的想法，然后把这些想法通过具象的手段表达出来。一定要合理，万宗逃脱不了合理。哪怕是猜的想法做出来的东西（他也说不清，不怪我咯），也一定要让自己觉得合理的想哭。然后拿着这份合理和PM继续彻夜长谈也许会突然发现产品雏形出来了。加一句：合理中尽量要细，有些人说这个阶段给个框架就好。我只想静静看一会你那套老生常谈，看你怎么继续，然后呵呵。对于什么都不清晰的产品给个框架有什么用，有什么用，继续在黑夜里高唱黎明来临吗？这种情况你需要基于有限信息去创造，而不是把文字翻译成线框图。细，不是说这个阶段的方案要细如发丝，最起码要把主要的流程串起来，不然怎么知道是否合理啊！啊！臣妾的脑洞不够大，光靠想象是做不到。你要是行，你上。

案例二：需求量撑破宰相肚，专业名词堆成山

这种复杂体现在多上：需求文档洋洋洒洒几十页。打开这样的需求文档，我会哆嗦的想找掩体-这是80岁美国老牛仔霰弹枪打靶的墙靶，多到这个份上，模块之间内容相互穿插成紫外线防护网了。专业名词一大堆，我怎么都看不见写的是什么，我失明了吗？哭哭哭。

就是这个样子，需求太多PM理不清的时候，容易  写  穿  插 了，这一块那一块（我知道他们不是故意，可我还想打他们）。我该用我的眼泪冲的海晏河清吗，省省吧，馒头都没得吃。爬起来，久病成医。对于这种需求只能读，读一遍、读两遍、读...     然后问问问，因为全是专业术语笔者傻啊，看不懂。顶着PM鄙视的眼神（潜台词你咋啥技术相关的都不懂），问一切他看似弱智的问题。

读完问完之后需要理清这些需求之间的逻辑关系。笔者又要欺师灭祖的胡说八道了，书上会让画一些流程图。几十页文档一张流程图，你是在织一张找不到头绪的网吗？画完之后，你真的会拿着放大镜拉着线一条一条顺着看下去吗？我给你倒杯水，顺万这遍接着再顺一遍。我先走，你继续。

这种方式不可靠的地方还在于，在需求还没完全了解的情况下，试图用一种框架框住这一切，完全是本末倒置的方式，在设计阶段你会按这个框架去设计吗？还是在设计过程发现不太合理，再折回来重新画一份流程图。最后再强调一下产品类型，产品类型啊亲，这种产品不是几个flow就能简单表达的，那套流程图的老黄历真的不是适合这样的产品（多，复杂，专业名词）。画个图比文字文档还复杂，有什么用，架不住啊。

对于需求文档信息量比较大的情况，笔者会推荐你直接在word的左侧目录里理他的逻辑。通过PM了解每一个模块的每一条内容，一定要特别深情的看着PM的眼睛问她(要是美女就赚大发了，哈哈)，你确定是这样吗？是这个意思吗？是应该在这一模块吗？三遍，一定要确保大模块分类不出错，细分项只要对应填进去就好。

最重要的是大模块是山的轮廓很好定下来，而细节则需要很多打磨，调整，调整，调整才能找到合适的位置。也就是说在这个阶段是需要了解每个大模块做什么，而不是把每个模块怎么联系，通过读几遍需求文档的就定下来，这需要我们在设计阶段在模块内统一斟酌。

对就是下面左图的样子，而不是右图那个死样子。左图就是让人了解大模块的关系，把模块的内容吃透，暂时不做关联界定。而右图就是想通过流程图把一切，everything 的逻辑在需求阶段理清，可能吗？能定下来吗？

对比以上两种处理大量需求的方式，以人打比方。目的是通过一段描述来呈现一个人，而这个人又是完美的，只有一种答案，而这种描述又不是那么清晰。人好不好看主要看蛋白质表达啊，肌体的蛋白质表达是通过基因确定的，而不是拿肉铺在毛细血管上。前者画流程图相当于通过描述的细节猜测细节，来铺人的毛细血管然后就ok了。后者通过对大模块的描述进行分类，相当于确定人的五官位置。然后通过模块里的细节摸索这个完美的人的基因表达规律，进而以较高自由度进行推算排布较准确的表达。创造性的工作本身就需要自由度，切莫作茧自缚，往笼子里钻。

笔者也是这个方法的受益者，无耻的自恋一下：写硕士论文的时候我都是把每大章的模块定下来，然后每天去填充里边的内容，这样就会逻辑特别清晰，丝毫没感到写那万恶的论文特别累。虽然最后差点没毕业（打脸啊），管他呢，论述本来就是仁者见仁（自我安慰）。

设计阶段

还是会崩溃，这么多的需求让笔者如何下嘴，不是，是如何下手。延续上面需求分析的工作，如果你是按照大模块理清逻辑，理清具体内容细节的方式来解剖需求的，那么你可以把大模块的逻辑直接迁移到Axure的目录中(笔者公司是用这个写交互文档的，工具从来都不不会成为负累，不用担心用哪种)，把主要节点（即人的五官及枝干）搭起来。

对就是这个样子，一定要把需求文档在word导航里，能够万分确定的模块按结构逻辑迁移进来，这样可以确保大方向不会错。

里边的细节就可以天高任鸟飞了，施展你的闪转腾挪，耍一段漂亮的花枪吧。真想打自己一巴掌，里边那么多内容，全是网你还闪转腾挪，把你绑成粽子，泪洒钱塘江吧。

对于这种界面信息满的像马蜂窝，表单长的像床（真想躺在上边睡觉），tab多的能铺城墙，我如何才能与她舒然起舞，愉悦身心。减，减，减，笔者也知道精简的信息量对用户来说，是多么的爽。就像一张白纸总让人觉得特别的干净，还有特别多的美好想象空间（可能有些人有不好的），但同样大小的苏菲玛索图片（笔者完美女神，美的令人窒息），看时间长了也会生厌，甚至还会发现一些缺点，皮肤有些斑点，鼻子有些歪，构图不好，光影不好（我是在丧心病狂的说胡话，对不起女神）。

但产品就是这样，每天都会深情的对着用户。如果颜值不高还密密麻麻，让用户怎么去喜欢你。如果你说复杂的也很美，那你要是能做成巴洛克、维多利亚风格，我会叫你artist，但不是designer。用户不光看，还要用啊，吓不死也会被累死的。

笔者是极简主义者，每次都想减，但每次都被PM和RD联合打的鼻青脸肿，落荒而逃。这也是事实，谁让你是功能性软件，那么多功能不实现没有领导会买啊，领导都很精明的，花同样的钱肯定想多买一些功能，反正也不是他用，他也不会累。既然暴力删减不成（城管也会被打），只能曲线救国了。减不了，只能藏起来，尽量呈现给用户重要的。这虽是比较常规的处理方法，但是能治病啊。

对于信息而言，删减的，隐藏的，呈现的的重要性，自然是呈现的信息>隐藏的信息>删减的信息。需要对信息进行排级排序咯，这样才好取舍（谁让是一夫一妻制呢），下面是笔者推荐的方式。当你犹豫不决去舍弃哪个一个时候，可以把信息统统丢进以界面信息操作频率、重要性元素为坐标值的坐标轴中，直观表达你的情感，然后愉快的去做决定吧。如果你再看不出来，一定是我瞎了。

当然只要你认为万分该删除的，要学会用你的眼神说服PM，毕竟他们才有生杀大权。对于剩下信息的处理方式，是隐藏还是分类，怎么闪转腾挪，要保持界面的一致性，可用性，易用性等一些指标我就不在各位大咖面前班门弄虎了。慢慢去打磨，多些耐心，只要你的五官没长错地，推理尝试找到美妙基因的表达方式，相信你的产品会变成你的Elegant lady（画线框图民工的鸡汤）。

最后插一句，在设计阶段像局部模块的逻辑判断流程图还是要画的（这个和整体看不清的流程图完全不同）。因为产品逻辑复杂造成流程复杂，逻辑流程图能够帮助我们看清楚flow的种类，防止遗漏掉场景。

设计评审（卖稿）

在评审的过程中，PM与RD会经常“害羞”的说，我觉得这不好，但我也不清楚哪不好。顿时笔者心中万千......

淡定，因为手里没有刀。笔者认为设计师应该有限度的妥协，限度要小，小的范围是发现更好的解决问题的方式。毕竟沿着路走了那么长，不合理早出轨了。不要轻易对自己说不，没有一个人比你在出设计方案的时候想的更多。那就去说服他们吧，检验产品最有效的方式是用户使用，但在产品设计阶段可用性不高，用户看到线框图或许会给你一巴掌：做的这么难看，还不能动，让我怎么用。况且是企业级的用户，哪那么好找。所以在设计评审阶段，构建虚拟的用户场景模型（口述）会异常有用，通过这个模型去发现用户怎么使用产品。但这个模型的构建需要去了解用户，又绕回用户了。理想与现实的距离，欲哭无泪（无言）。

所以平时需要多与PM把酒言欢，谁让他们接触的用户多呢，多从他那获取一些用户信息。在尽可能多的信息基础上去构建用户场景模型，尽可能的合理，这样才能把稿子卖出去。当然这个用户场景模型的构建应该处于需求分析、设计阶段，只是在这里说明评审的时候能帮你把稿子卖出去，而不是说在这地方才着手构建，不去严格的去罗列这些流程了。

但第二手资料有一定的风险（食人牙祭能好吃吗），需要时刻对构建的虚拟的用户场景模型持自我怀疑的态度，不断的去发现问题，然后不惜一切的代价去了解用户（可以为所欲为），进而去纠错。这个机制的容错机制想必各位大咖门清，不再赘述。

还有一个常见的问题，RD们可能会不自觉的回避难实现的技术方式。或许他们没有考虑到此种丧尽天良的行为，对产品用户体验造成的影响。RD大哥你搬的砖是轻了，可到用户那里菜量不够会被投诉啊。

可能在他们眼里，你们这群死美工啥也不知道。但我们需要去了解他们的心声（谁让你不会写代码，谁让你倒插门呢），用你对追设计的追求（死缠难打，晓之以情）感染他们。其实和他们深入沟通后（不要误会，我是直男），会发现其实技术的实现上和用户体验都有很多相似之处，只要合理的，能说通的东西，都能引起共鸣。最重要的是你能发现他们贼精贼精的还是能实现的，只是偶尔想打个盹。

不知不觉写了这么多废话，明天还要上班，就写到这吧。以上纯属一家之言，但都是切肤之感。实在是学识浅陋，表达有限，如有一句可读，作揖。欢迎各位大咖吐槽，指正。思想有碰撞才有火花（火花有很多种，坏笑）。

今天写这么一无节操的东西权当娱乐自我娱乐看客吧。笔者平时喜欢写一些婉约的情怀，本性难易（狗改不了...）最后再矫情两句吧。

凄风厉雨，我独取一瓢苟且，苟且着每一片值得的风景。

（注释：即使你虐我千万遍，我依然默默坚持我的坚持，不明白为什么，可能已经流入血液。我的能力不足，懒惰，但我不会让我的坚持落后于能力，对生活对工作都如是）。

晚安，如果有人看。