求助：前端负责人对需求和ui如何评审？标准是什么

前端需要评审什么，产品只要原型能设计出来就能做

产品不专业，或者考虑不全，前端不评审，很大概率功能要回炉重造

产品不专业就按自己想法去设计，做完后直接让产品去看，如果说不行你就吊他，前提自己技术得够

公司有固定流程，不是想怎么搞就怎么搞 ^-^

基本上都是业务需求，很少有前端打回的，除非是专门的页面ui重构或者展示不合理

是的，业务需求一般是逻辑不闭环才打回，但ui展示不合理怎么评判？从哪方面入手，佬有没有例子说说

除了有实现障碍或者严重的性能问题 单纯前端维度很少打回吧

前端我感觉就是看不看能不能做、能不能不做、好不好做、交互流程是不是现有的冲突，业务实现合不合理

比如有更好的展示方式啥的，这个很难说了，就是一行展示多少个，展示不下了，是不是有其他方案啥的，选展示的字段啥的方式啥的，反正我碰到的很少前端有异议的，基本上都是后端确定没啥问题就开干了，然后可能就是渲染性能问题啥的

是的，需求方面大概是这样，主要是ui方面，毕竟前端跟ui挂钩

业务流程的话看看某些地方要不要二次弹窗确认啥的，基本上也没啥，前端老大开完会主要任务就是分活

好不好看，功能合不合理和前端严格来说是没关系的，你可以有想法，但是只能说是建议产品和UI去做调整，但是这些都不属于你的范畴

是，但流程上就说有前端评审这环节，为了减少回炉重造的可能性；可能我上面表达有误；其实算是对产品和ui的建议调整

首先最基础的就是要评审工期要求、复杂度、人力配给，

然后主要评审某些交互是否匹配公司级组件库的相关能力，非必要禁止魔改统一的交互和样式；

一些复杂动效是由纯前端实现还是配合设计团队实现；

需求中是否涉及当前架构无法实现的能力，比如跨域 iframe 嵌套；

是否特殊的适配需求，比如无障碍、移动端自适应等。

佬，太有用了，还有个问题：对于ui稿件的页面展示、或者布局，需要从哪些地方去审查是否合里，对于前端方面的，然后给出建议

前端方面好像没有那么严格吧。

需求是否合理取决于你的任务工时分配、渲染性能。

稿件标准，如果有公司ui库的话尽量别魔改，以ui库为标准。用户方面考虑是否好用，是否容易误触什么的。

具体也就是协商改点小问题，人家产品既然定了肯定是上级领导点头确认过，不像后端改了领导基本无感。

其实如果 UI/UX 是个合格的同事，一般输出的稿件问题都不会太大，都会采用设计团队内部的设计规范（一般也会符合前端组件库的设计和交互）来输出需求稿件。

前端不必只局限于布局和展示，一些前端专有的点在需求上可能更容易出现问题；

还有因为前端是比较靠近用户侧的，相比于设计团队也更理解产品，可以从用户侧的角度评审一些交互问题，比如功能交互入口是否存在不统一导致割裂、新功能的引导是否有更好的方案可以降低用户的心智成本、交互路径过深可能导致用户触达率降低等等。

产品是新转这项目，在旧项目迭代，有些需求会考虑不全，所以减少回炉，这边需要给他们把一下关，主要是逻辑回环，其余没管

至于ui，用的是el，但是都是在这基础自定义设计了

所以问问佬友们，还需要参考哪些方面