设计沉思录：「推荐好工作」项目流程总结

2017-09-21 09:54:00

文章未「推荐好工作」这一项目的流程总结，希望能够给你带来些借鉴参考。

在互联网产品越发成熟的今天，产品迭代的速度也是非常快的。而项目流程是影响产品迭代速度的重要因素之一，每个团队都有属于自己的流程。那什么样的流程更有利于的项目的良性循环呢，结合我最近参与的一个项目，以UI视角来看看项目流程里出现的一些问题，以及怎么解决这些问题。

项目背景

推荐好工作是赶集创新招聘项目，率先在M端（移动网页版）上线。经过调研发现，目前赶集APP平台上找工作的用户，有相当一部分用户群体是迷茫状态，并不清楚要找什么工作；全职找工作的用户中，有1/3的用户会选择跨行业找工作，基于以上两点，将全职工作中通用类型的工作、以及对专业限制较少的学徒类工作推荐给用户，帮助迷茫用户发现合适的岗位和工作。

本文是针对项目流程的总结，而不是针对项目本身。接下来按照收集反馈-梳理流程-解决问题这个思路来给大家分析。

收集反馈

在项目上线以后，回过头来反思我们的项目流程，首先收集了项目团队各个角色（PM、交互、UI、FE、RD、QA）的反馈，主要针对在项目的各个环节里遇到的问题，以及与其他角色合作时遇到的问题。

从上图中可以看出问题主要是输出和流程两类，流程类问题会更多一些，所有的问题都不同程度地影响了项目的进程和最终的呈现，影响了用户体验。

梳理流程

一个项目的基础流程是：需求分析-交互设计-视觉设计-需求宣讲-开发-测试-视觉走查-上线（仅代表赶集设计部），我们用体验地图的方法将问题按角色和流程两个维度来分类，有浅灰色背景标识的是跟UI相关的问题。

从表格中可以看出，在项目的后半个阶段问题暴露的比较多。我们在这里只分析跟UI同学相关的问题：

不了解项目背景（视觉环节）
视觉图与文档有出入（开发环节）
还原度不够、未及时得知需求变更、RD修复UIBug有时间风险（视觉走查环节）

解决问题

逐个分析，不了解项目背景。现有的方法是，需求确认之后是交互执行，然后是视觉执行。在设计之前，设计师需要做竞品分析、市场评估、消化需求等工作，而在这个过程中会产生很多疑问。这时设计师就得回过头与PM或交互沟通，这个时候项目流程就是反向的，PM或交互不得不与UI复述一些已经讨论过的问题，这样就极大地影响了效率，也不利于UI设计师掌握主动权。

如果在PM和交互沟通之前，叫上UI进行一次需求预沟通，这样大家对需求的了解会比较同步，UI也可以提前开始准备工作。当PM和交互同学定稿时，UI同学再次参与进来，解决需求里的疑问点。

现在看第二个问题：视觉图与文档有出入，这个问题PM和RD都有提到，视觉图和文档有出入是由于开发动工之前，PM、RD、UI三方没有核对设计细节，信息不同步。例如在需求宣讲的时候，由于技术或需求点的变更，PM和RD达成一致，而UI同学并不知情，直到视觉走查时才发现。如果所有涉及的角色都参与到需求宣讲会议，有问题及时调整，视觉图和文档不统一的问题也就迎刃而解了。

第三个问题都是与设计还原度相关的：未得知需求变更、还原度不够、修复UI bug有风险。设计还原度一直是不被重视的却非常重要的一块。有些时候在开发的过程中由于一些不可逆的因素，需求会有些变更是无法避免的，但是这些变更必须及时同步给UI同学，方便后续快速调整设计方案。有些RD或PM同学对界面还原度意识较弱，然而开发的还原度，会直接影响产品最终的用户体验。

作为设计师面对所有步骤不能一蹴而就，视觉走查环节是正式上线的前一个环节，所以这个时候任何改动都需要评估风险，推动起来难度比较大。试想如果我们能早一点发现问题，RD解决的时间相会充裕些，风险也会小很多。FE和RD完成联调提测后，UI同学可以和QA同学并行走查，让问题提前曝光，及时排期解决。

在走查中有个小技巧分享一下，通常提测以后，无论是PC端、M端、APP端的项目都可以预览线上开发的还原效果，我们可以先看完整体页面，列出问题list，比如以表格的形式（如下图），等RD哥哥姐姐改完Bug我们再去验收，这样就成功将体力活转换为眼力活，避免来回跑。当然需要当面沟通的问题也需要积极的配合。