纵使你是个小公司UI，也需要出一篇出色的设计文档

        写这篇博客，是因为博主在工作中正遭受着狂风暴雨般的碾压。

        如果你在小公司工作，而很不幸，和博主一样也是一名UI设计，那你一定能懂没有需求、沟通不流畅、设计难以产生价值的痛苦。公司没制定合理的工作流程，也没有任何技术、设计规范，甚至没有产品经理、开发一言堂，那贵司的产品一定会面临反复修改、不定期推翻逻辑、每天增添需求的惨状。而老板提需求、开发定产品最终导致的后果就是UI改改改、还要背锅。

        其实工作背锅并不可怕，工作的反复修改、无效加班等问题浪费了大量的时间成本。项目急上线，口头传达大致工作、然后员工指望在后期对接工作中完善修改、达到功能统一，看似简单粗暴，实则欲速则不达。而一篇细致入微、及时更新的设计文档会成为工作效率的催化剂。

        当然，作为一名UI设计师，纵使你有这份自信，但是也很难产出一篇专业的产品经理们也为之头疼的需求文档。所以这篇文章主要设计视觉部分，稍涉及交互，毕竟没有产品经理的小公司，很难提另招一名交互设计师产出原型图。当然，目前市面上很难百度出设计文档的具体要求，博主也没有什么大型公司的从业经验，只能根据自身实际情况出发做整理，读者们可以辩证吸收。

一、编写目的

        设计文档的产出不是自嗨，是要切切实实服务于工作中的，那么这篇设计文档给谁看，会涉及到你的文档出到何种深度。如果你的设计文档仅仅是给到前端出排版，那么你的设计文档读者应该是老板、运营、前端；但是如果你的研发工程师同事们正嗷嗷待哺地等着你的页面写逻辑，那么你的文档中必须涉及交互逻辑、功能点、业务逻辑等等开发们感兴趣的内容，当然这也要求你再撰写的时候多与开发沟通，毕竟技术上，他们是专业的，问清楚他们想要什么，让设计文档更清晰。

二、项目背景

        也就是项目名称、项目目的（公司在何种情况下要做此项目；如果是版本更迭，那么出于何种考虑做出更新）、本次需求的版本号、完成时间等。这样方便同事们区分文档的更新进度。

三、项目目标

        也就是该项目完成后，需要达到什么效果。此处可结合用户量、用户增速、项目目的做出详细延展，让同事们认清本次项目的意义，防止个别同事因种种原因乱砍需求，导致整个工作链多次返工。

四、项目分析

        此处叫项目分析而非需求分析，是因为需求分析其实是需求部分的统称，而项目分析，实则分析的是需求。我们可以结合竞品、结合项目的目的、结合工作的目标，分析出我们的项目需要的功能、功能要达到的效果、功能完成的流程等等。此处也可看成是一个总结，让你的同事整体看到需求的描述，接下来的一些部分则是具体表述为何以目前制定的交互方案、视觉页面来完成该条分析出的需求。

五、场景分析

        这部分可根据需求制定人物画像、描绘应用场景。本部分要格外注意的是，人物画像并不能因性别、年龄、职业一概而论，而是应该以特定的使用人群而区分，如共同应用产品的目的、  相同的动作原由等。当然，性别、年龄、职业等确实是影响以上的某种因素。应用场景可用文字描述，也可用简单的漫画描述，这完全看个人偏好，在这不做过多阐述。

六、功能归纳

        项目分析过后，肯定需要归纳总结出功能点。本部分不能单单列出有什么功能，而是要列出功能在应用场景中如何实现。因为有些功能逻辑复杂，所以可以做出瀑布流式的流程图，这样开发工程师会对本部分的逻辑一目了然。

七、页面展示

        这一部分可在页面产出后加入进去，切记一定要放入最新的页面，以免混淆前端开发的视听。这里的页面一定要是所有人审过的正确页面，如有更改，连带前文的需求以及此处的页面一并修改。

八、设计风格

        每个APP都有自己的性格，让人一眼就看出这是“网易云音乐”，而不是“酷我音乐”。这一部分主要是确定设计风格、设计色调、icon风格、排版标准等。UI要求icon的风格、尺寸、线条统一，排版时图片与文字的距离、字号、颜色等都需要统一标准，当然这需要设计师自己根据实际情况而定。每一项都要标明原因，以此来说服他人，同事，如果有新的设计入职，也能很快上手。

九、设计规范

        每个公司的开发人员都有自己的工作习惯，尤其是小公司，员工水平良莠不齐，之前的工作习惯很难与其他人达到统一。但是不得不承认，程序员的一大特点就是自信，认为自己是最牛逼的，这种情况下，老板也不是那么懂行，你教不会他如何适应你用的尺寸、切的图，那就多沟通。做事之前问清楚他想要的尺寸、标注方式等，落实到文字请他确认，这样节省了对接成本，也减少了工作误会。

        以上是博主的一点体会，如果是在有产品经理、工作流程专业规范的成熟企业或许并用不上，但如果是在小公司、你也有同样的困扰，那希望这篇文章能给你一定的帮助。