产品到设计，设计到开发，其中 UI 效果图应该做到什么程度？

[CSGO]

本人 UI，现在在实际工作中出现这样的问题，就是产品给到的原型图，或者叫功能需求图，就是简易的文字布局，没什么逻辑性，我通常拿到，我还需要重新理解整个项目产品要做啥，然后开始配合图，研究产品到底需要做什么，然后开始画 UI 图，但是实际比如一个登录页面，其实会牵扯出一堆图，包括错误、输入错误、注册、验证码等等，而这是相对于通用，也是理所当然的能想到，但是对于实际开发 app，自己公司独立的产品内容，没有的参考的时候，UI 图充当了交互，图会越来越多越来越复杂，而当然如果项目时间充裕，也没啥事，就是慢慢用 UI 作出一整套交互逻辑。而开发也都是看着 ui 图开发，又是一系列看文旦，不断看 UI 设计图，来看到底要做什么，以及每一步的交互，然后也许可能会发现哪里有逻辑问题，然后又是我这里加 UI 图；而这些都算好，更多时候，是产品那里又不断地变化，我又需要不断开 UI 图，而因为仅比如登录页面，只要有个新东西加进来，我一整套登录页面的 UI，又都需要改一边，这样偶尔改也确实没啥，问题是，在紧急的项目中，这种改动会更频繁，以至于我现在回头看了 UI 上的版本，一周中平均一张图一天需要更新 2 个版本。这应该如何是好？

[sun4912]

把 PRD 打回呗。
UI 是根据 UE 来的，注重最终呈现的视觉效果，而不是逻辑。UE 才注重“前端”的逻辑和用户路径。
而 UE 又依赖于产品提供的原型和说明。
所以不是你的锅。

[learnshare]

需求文档、原型图、UI 和交互最好都有，内容当然是越完善越好了
实际合作中：爱咋咋，先做完上线

[wldouglas]

其实大多数人对于 UI 的理解，还局限在过去的几年里。那几年国内的设计慢慢起步，设计上划分比较清晰，比如视觉和交互设计。其实 UI 的英文大家也知道就是 user interface - 界面设计，无所谓交互和视觉。Apple 自家一只以来出具的 HIG 也是指用户界面设计。这是早些年的概念，现如今，UI 在大多数转变成为 UX. 也就是用户体验设计，这里包含的就更广了，如果楼主是一个上进的设计师，那么就应该往前走一步，到产品的层面，对于设计有商业层面和产品层面的思考，随之而来就是对于需求的快速理解。那么有没有 PRD 就不重要了。特别是在创业公司，没那么多闲功夫去写这些书面的东西。自身定位于产品设计师，从商业层面拆解到产品需求，到设计目标。出设计稿，就意味着出具详细的设计推演过程和说明。过程和结果有理有据了，合作方就会买单，变动是大概率不会出现的。至少以我的经历来看，几乎很少变动了。

[fenx]

貌似楼主的重点是紧急项目中的频繁改动？那这问题源头不在 UI 上，没法决定什么的时候就只能照常出图了（？）

[v1]

你们需要一个交互设计师

[morizawatt]

其实增加一个功能就算迭代了，有可能是需求方突然想加的，也有可能是 pm 没想周全后加的，反正锅不在 UI 这里。再一个不知道你用 sketch、xd 还是 ps，灵活运用”组件”，而不是复制粘贴图层，小改动的话，改一张稿就可以了，效率会快很多。

[xiusheji]

把自己的专业方面的知识都巩固好，你说的这些问题都可以自然应对。
自己的工作范围会很清晰。

[xiusheji]

比如登陆界面：
1、明确自己为什么这么做，这么布局，要有明确的立场和方法支撑。
2、输出的东西要完整、规范，经得起别人的质疑。
3、面对需求变更、多问为什么。需求有没有经过评审最终决定？需求变更的好处？需求方有没有做好版本或需求的时间规划？如果自己来做预估时间多少？自己作为视觉要提出是否可以变更的建议，把后果和优缺点提出。
4、还有就是提升效率，排期—草图—软件界面—沟通修改—交互动效—沟通修改—输出

[yogedai]

给楼主提供一些选择：
1. 把这个产品挤掉，直接把他的活接手完事儿。
2. 优化自己和开发之间的工作流，有些 UI （比如我），不出“错误、输入错误、注册、验证码”这些图，文字说明完事儿。
3. 跟产品之间拖延时间，半天能出的修改图拖到 2 天，产品一看花的时间长，自己也会慎重些（不是喊你摸鱼，时间还能干别的工作）。
产品后边往往还有老板，老板都是一直到最后一刻都想修改设计图的人，讲道理反正是不管用的，只好靠你自己努力了。

[tatacheung]

输出设计规范，以后所有错误提示、对话框的开发和设计直接按照规范去做就可以了。