一般的项目中UI是非常重要的一部分，我们今天谈谈在敏捷开发交付团队中我们是如何创造UI的mockup以及该UI是如何到DONE的。
我理解中的UI分两个部分，第一是样式，即这个页面长啥样儿，用啥字体，有啥样的style guide等等；第二个就是交互，何时能点击某个button，请求成功或者失败应该发生什么等等。
正常的能够到ready for dev的带UI的story都是这么来的，在了解了下个迭代的需求之后，UX会根据需求draft一个mockup出来，然后跟相关需求的BA到一个小黑屋碰一下，俩人讨论的结果没问题就会把mockup放到该故事卡里，并且上传到zeplin这样的工具里供开发参考。这个mockup不只是说简单的一个样式，有可能一张卡里面有好多mockup，是不同用户行为的不同展现形式。我之前在TechOps项目的时候UX简直不要太好，她会利用invisionapp模拟这些交互，我们就可以随时去check哪个页面的交互是怎样的。
从上面的UI生成过程中可以看出，UI跟需求是密切相关的，不可能说需求里面没有一个叫‘A’的概念，UI上却显示了一个叫做‘A’的模块。那么必然UX和BA需要经常与对方交流信息。
那么到了开发可以开始做的时候，开发可能先要看一下这个mockup，一般来说都比较容易根据需求看懂mockup是什么意思，但是会经常出现在做的过程当中才会发现一些未知的参数，比如说如果要兼容IE那么我的input框尾巴那里的叉叉的样式是怎样的，再比如说我们需要一个icon但是还未上传等等。太多细节需要常常跟UX沟通，甚至有时候开发需要跟UX pair来一起完成。
从而可以看出，UX和DEV也需要常常互相交流来确认设计。
我是一个非常幸运的开发，在以前所有的项目中UX都是我们自己人，完全精通UI的设计理念，也懂得如何顺畅地跟BA以及开发合作。而在现在的项目，客户爸爸由于某某原因用了另外一个vendor的UXs。这里有两个问题，第一是由于remote，沟通是不方便的；第二个是有时差，当有了问题只能邮件去问，然后就是等待回复。在经历了第一次合作之后我发现了另外一个问题，她们貌似不是根据story来创作的，需求里面有的东西她们不给，需求里面没有的她们却画出了，画出了样式之后也不考虑交互，当我们提及交互是怎样的时候，她们却回答说还没想好。这时候我才觉的，我想念我们的UX！但是比较不错的是，她们在sign off这些mockup之前会给我们先看一下，所以可能开发要多考虑下，不能按照以前一样什么都是设计好了的，我们得全方位地每一个细节地想好，还有什么是她们应该考虑而没有考虑的，也不至于因为一张mockup catchup了7，8次最终才确定。
在与别人家的UX合作方面道路且长且远，也许自己也要想想如何最大限度地避免沟通成本的浪费。
网友评论