对互联网产品而言，验收有三层含义：

产品功能用例化后，用例执行符合预期

与需求吻合，正向操作的用户体验良好

设计和前端UI符合评审的标准

第一层应该是测试人员应该重点关注的，但在小公司或创业公司，开发/产品本身就是测试，验收几乎等同于最后一次测试。但是无论是否有“测试工程师”这个岗位，产品需求的用例化都是十分必要的，即便通过了专门的测试，产品或领导在验收时，潜意识也是在执行相关的用例；

第二层说的是普遍意义上的验收，产品通过test平台测试，部署到了DEMO平台，由产品需求人员进行需求验收，当然，内部成员、相关领导都可以进行验收体验。对DEMO的验收，是“装成用户”后对产品的使用，通常是正向操作，同时除了逻辑和流程，验收人员会更加关注用户体验；

关于前端UI的验收，实际上是对“用户体验”的一部分标准化，而验收的内容应该与“设计评审”通过的内容相吻合。如果没有设计评审，那么标准就是公说公有理了。为了避免这种情况，需要在需求和设计评审前，界定清楚一些基本的准则和规范，比如符合公司的VI体系、符合W3C页面标准、符合XXX，最直观的还是所见即所得的“需求设计交互页面”

这个问题其实很好，好在专门提出了UI的验收。本质上是因为开发对UI或者对前端、兼容性等很容易忽略，因为这是个“简单但很花时间”的活儿，做起来没有成就感。当然，如果你们有一套自己的UI库或前端框架，那么能够规避很多前端上的扯皮，但如果没有，开发和前端至少需要50%的精力去搞页面。提前考虑标准、尽量使用框架、让代码公用并易于维护，这是前端和攻城师的硬功夫，否则就沉浸在无尽的BUG中，更不用说验收了。

至于谁负责？团队中的任意相关人都可以，前端、开发、产品、或者你们领导。总之，验收就是质量的最后把关，产品自己都看不过去，臭虫一堆，千万不要有任何侥幸心理让用户帮着验收。不过就不过，KPI都是浮云...