最近在做公司的一个新项目，心血来潮想总结下我做这个项目的工作流程。因为一直都有想写一篇关于自己工作流程的文章，终于把思路理清楚，开始码起来。
任何的工作都是不简单的。本文主要就是描述我个人的工作流。实际工作中做的内容可能会比这里描述的还要详细些。
附上目录，然后再对其中提到的流程项一一进行解释。每个人对产品的理解不一样，工作的流程也许也不一样。这里仅是我的一些总结，要是看官们觉得毫无价值一笑而过就是🤡🤡。
1.沟通需求+搜集资料
当接到设计任务时，具体要看和你对接的项目经理或产品经理给到你的文档到底有多细致，如果不清楚的地方当然就是沟通了，工作中沟通是很重要的。从接到的文档中，了解、分析需求，搜集相关产品资料。这次我接到的是APP功能清单文档及已完成的web端管理平台地址和账号。
在不知道产品背景、产品目标、目标用户的介绍。只能从web端页面，功能清单了解到该应用是一个管理及监控蓄电池的应用。沟通知道，应用的用户群是电站的保安及管理人员。
之前在掘金看到一篇用户体验的文章说到产品的分类 。
产品分类：功能型的的平台类产品，关注的是任务，所有操作都被纳入一个过程，去思考人们如何完成这个过程。信息型的媒介类产品，关注的是信息，产品应该提供哪些信息，这些信息对用户的意义是什么。
看了到手的相关资料后，知道这是功能型产品。也明白了产品功能框架不算复杂，信息流分支也清晰。开始资料搜集过程：
- 搜竞品
会到App Store搜索同类产品，把能想到的关键词都拿来搜一遍。由于很多都是供内部人员自己使用的产品，即使下载了APP，没内部账号是看不到应用内页的，只有看看应用商店的截图，然后截图保存下来，方便随时查看。 - 网上查资料
我还会到网上搜一搜，看有没有同类产品的网站，进入网站看看关于产品的介绍，以此了解这到底是个什么应用。在看了十几或者二十几个产品后，心里面应该大致有个你要规划的APP的信息架构了。之前有看到一位笔者的文章说会参考上百个APP。时间紧任务重的亲们还是平时多积累，以免要用时才发现时间不够。
2.梳理产品信息架构
我一般会用xmind来梳理，对照着功能清单、web页面、同类产品截图，梳理飞起来。
信息架构其实也就是你要设计的这个应用的信息层级。信息架构梳理完了，这个应用的功能也算规划完了。接下来就是出交互稿了。
3.绘制大致交互线框图+对接上游
交互的过程主要是负责与上游的对接，把需求转化为功能，推动项目按照计划完成。上游即是交给你设计需求的人，或许是产品经理、项目经理、市场部等，也可能你的终极大 boss提的需求@～@
通过axure的站点地图其实就可以大致看出应用的结构。站点地图的结构与xmind梳理出的产品信息架构是保持一致的。规范的交互稿是应该配上更新日志的，记录交互稿的更新信息，便于日后的查看。
业务流程图：描述应用内个功能间的业务关系、顺序和信息的流向。
交互稿：交互稿包含了流程图、界面图、交互说明等。
飞机稿：用于存放被废的页面，以防后期可能会用到。
交互稿的站点地图每个人有每个人的建立方式，只要便于查看，结构清晰就好。此次应用的线框图其实是并没有画完的。项目经理希望尽快给出可供开发直接使用的页面，即交互在视觉稿中进。因此后续就没画原型，直接上手视觉效果图了。
展示一张交互稿页面，页面中大致包括：页面必须的元素、交互说明。平时也会画web端的原型，放张比较干净点的，交互细节说明比较少的，web端很多都是靠沟通和概要设计去说明了设计思路了。
今年5月下旬的时候负责的这个模块的设计相关工作。一些页面的跳转都是直接与负责这个模块的开发人员及时沟通进行的。
4.视觉设计
- 定风格
首要任务就是解决主功能页的设计，以此确定整个应用的视觉风格。主要确定的内容包括颜色、字体、图标三大块。 - 出视觉设计规范
风格确定以后就可以出一个对应的视觉规范。视觉规范主要应该包含:规范说明、颜色、文字、图标、控件样式等。后续的设计都参考这个规范，同时也保证了界面输出后风格的统一。当然规范是死的，设计是活的。针对应用中的特殊页面，我们需要先学会规范，遵循规范，再去打破规范设计。 -
加入UI成员，赶进度
定下设计风格，出个别页面和视觉规范后。我的工作算是完成的差不多了，再加入一个UI妹纸，赶设计稿，追进度就OK了。在设计过程中，我也会经常和UI妹纸沟通，确认页面元素，毕竟没出原型嘛，还是沟通解决问题了。
首页样式筛选
5.对接开发+优化改善
视觉稿的设计过程中，都是出一部分，然后与项目经理确认。确认后的页面就开始切图定位，上传SVN通知相关开发人员。开发人员在未拿到视觉图的时候，前期有接到原型图的就按原型图搭界面框架，切图到了就替换。没有原型的也会看功能清单摸索着搭。出的视觉稿只要确认后，就会立即切图定位给开发。Android和Ios并行。
开发完成后，就叫开发人员给你的手机安装个测试下。或者公司有多的手机，你也可以借一个来测试。主要是测试下实际开发出来的和效果图的区别。我会把开发出的界面截图，传到电脑和效果图对照着审。最后把不同的地方标注出来，以文档的形式发给对接的开发，麻烦他们对照着调整下。
最后补一点小结
整个的流程其实也就是把需求转化为功能，功能转化为设计，设计成功落地实现的过程。
我在本项目的角色是典型的UI/UX 通包的小团队操作模式。这样做的好处是你前期就可以了解业务情况与产品架构。这样在规划和设计起产品时就可兼顾到“好看易用”。
- 沟通非常重要，有什么需求上想不通的地方，要及时的反馈，有效的沟通。
- 设计工作中的交互稿是要做到信息交代得越详细越好，越精确越好。如果由于时间不够，无法做的很完善，那么就需要你和开发耐心沟通了。
- 设计交互稿、视觉稿的时候尽量不要频繁更新，会给人一种【很不专业】的印象，开发也会很烦你频繁的改动。
- 在设计产品中遇到瓶颈时，要想着换一种设计方法跳出现有的逻辑，或许就是另一翻天地。
