敏捷模式下关于UI/UX工作的几点建议

1.常态化交流明确需求

      去文档化是敏捷式开发的特点，PO（Product Owner）在传递需求时不会有面面俱到的文档，因此团队成员要在Planning meeting时要就明确需求，如有疑义会上及时提出来，确保在开始某个任务开始之前大家达成共识。

      UI/UX要做的不限于画简单的界面图，更多的要参与到产品的工作中，在PO提出需求后，UI/UX明确要达成的目标从而考虑对应需求的界面，交互，保证良好的用户体验，这里不断沟通是保证产品质量的重要因素，很多时候个人的主观想法与项目期待发展的方向会有不小偏差。

      因为原型图的限制有限，UI/UX有很大的发挥空间，所以只要是满足需求的，合理的方案都可以列入开发。有规则，也有自由。

2.业务设计需要闭环

      UI/UX在团队的角色十分重要，其工作内容相对独立，可以理解为连接产品和开发的桥梁——产品的需求由设计图呈现，开发的参照也是设计图。因此，再简单的业务流也要形成一个闭环，保证设计图的合理，让开发不再纠结于业务逻辑，更多的精力用于理清代码逻辑。

• 举个最简单的例子：下图是贝壳网站上一个新闻展示的部分

单从目前的前端页面上我们去挖掘后台这部分管理系统的业务逻辑，至少应该有以下几个功能：

1.新闻列表页（字段为：图片，标题，简介，标签，发布时间，操作）

2.新闻的“增删改查”功能

3.新闻的“增改”的详情要包括文章标题，简介，图片，详情，标签，所属分类

这些功能表现形式可能不同，但里面的内容缺一不可，少一个业务都不算完整，这就是这里所说的“业务闭环”

（这里还可以增加筛选，排序，置顶，是否显示，草稿箱等功能，算作是功能优化）

3.设计出图的提前量

      通常，UI工作要在开发之前至少半个sprint完成，这样在Planning Meeting时有利于开发准确预估自己的工时，很多情况下后端的工作也要早于前端开发，若此时没有原型图支撑，设计图便是唯一依据。

4.关于设计规范

1）何时建立设计规范

      敏捷开发中从0到1的新产品开发周期相对瀑布流模式短很多，留给设计师的时间有限。

      个人实践证明，过早的建立规范不切实际，这时所有的概念来自于空想，提前建立的规范不能匹配后续产出设计图时遇到的问题，并且此时产品风格也未形成，设计师在逐渐丰富页面的过程中极有可能推翻自己之前的想法，造成返工，效率降低。

      当然设计规范更不能在初代产品上线之后再去创建，这时设计师和前端开发在没有规范参照的情况下产出了大量页面，很难保证一致性，会造成产品视觉混乱，质量降低。若要在后期迭代再去纠正一些不规范的页面，返工量更大。

      建立设计规范的合适时机应该是在核心页面设计图产出之后，例如首页，个人中心页等，这时产品的风格已经确立，很多想法得到验证，从代表性页面提取元素建立规范确实可行。

2）纳入设计规范的内容

      如28定律所言，系统中80%的效果都是由20%的变量造成的，在UI设计中，大部分的内容可以由基础样式和基础控件完成，因此UI规范中只需要出现复用性高的核心内容，例如文字，色彩，布局，控件等，对于一些复用性低的部分便无需纳入规范。

3）设计规范的更新迭代

      产品在不断迭代的同时，规范也会跟着改变。所以，在建立规范时，要留有一定的余量，保留规范的弹性，方便后期拓展更新。如某个特殊状态后期使用频率增加，那便可以把它列入规范中来。若产品整体风格要大改版，应以原有的设计规范为参照，这样可以在保证效果的同时降低设计与开发的工作量。

4）规范的制作与保存

      可以使用Sketch进行设计规范的绘制，并将规范存放在团队成员均可见的云端，例如蓝湖。当设计规范更新时，名称中加入版本号和时间以示区分。

5.了解基础开发知识

      敏捷模式下的多角色直接沟通对设计师提出了更高的要求，不需要面面俱到，但基础的开发逻辑，开发概念必须要了解。

      互联网产品的可实现度较高，审视一个设计的价值，不光从视觉层面，更要看其是否能落地。一个产品从设计到开发的过程也就是创意到执行的过程，这其中视觉思维与产品思维缺一不可。

      当设计师了解基础开发知识后，他便能站在开发的角度考虑这个方案是否便于实现，这也是在一定程度上帮助开发解决了问题。与开发的对接效率提高了，团队的工作效率自然会提升。

      其次，懂得一些基础开发知识，能更多地了解到底层的业务逻辑，突破自身的限制，知道更多实现的可能性。

• 举一个常见的账户登录案例的逻辑

前端页面提供用户名，密码输入框，按钮（包括样式，不同状态等）

输入内容后，点击"登录"发送请求到后端

后端接受数据，根据输入的用户名和密码进行判断，返回给前端不同信息

设计师在设计页面时会考虑登录成功和失败的两种状态，纠其根本原因是因为开发所做的判断只有这两种，0或1。

总结

      以上五点建议可根据内容将其分类：团队协作（1），业务理解（2），专业素养（3，4），行业知识（5）

      由于敏捷开发的模式特点，设计师不再仅是设计部门的一员，而是贯穿游走于整个产品生命周期的重要角色。

      对开发而言，他关注的是产品是否可实现，业务逻辑是需要设计师和产品共同去考虑的；

      从用户而言，UI/UX的重要性要大于开发，因为用户不懂也不需要知道产品的代码结构或你的框架，他直接接触的是设计师设计的业务线，产品的界面样式，使用的流程体验等。

      这对UI/UX提出的要求便是全链路发展，在各方面获得一个能力平衡。