【脑洞小剧场】零帧起手创业小公司之 UI设计稿初稿
<前情回顾>
点击此处查看脑洞小剧场合集
https://blog.csdn.net/foyodesigner/category_12896948.html
<今日小剧场>
阳光透过办公室的窗户，洒在吴艾（UI工程师）的桌上，映照出他那张略显疲惫但又充满期待的脸。今天，他终于完成了那份被无数次催促、无数次修改的UI设计稿初稿。他深吸一口气，像是要把这份成果深深烙印在心里，然后满怀信心地点开了与产品经理程立新和前端程序员段码的群聊窗口。
场景一：UI工程师的“心血之作”
吴艾（心里OS：哼，这次的设计稿我可是下了血本，熬了好几个通宵才搞定的。程立新，你这次总该满意了吧？还有段码，别再吐槽我的设计“不切实际”了！）
他上传了设计稿，并附上了一句得意洋洋的话：“设计稿终于出来了，各位大佬请过目！”
场景二：产品经理的“颠覆之旅”
程立新（看到设计稿，眉头一皱，心里OS：这……这就是吴艾所谓的“颠覆行业”的设计？看起来怎么这么普通？我要的是惊艳，是让人一眼就能记住的设计，不是这种随波逐流的风格！）
他忍不住在群聊里吐槽：“UI设计稿怎么这么普通？我要的是惊艳！吴艾，你是不是对‘颠覆’这个词有什么误解？”
吴艾（看到程立新的吐槽，心里一凉，OS：卧槽，这程立新是不是眼睛瞎了？我这么用心的设计，他居然说普通？还颠覆？他以为他是乔布斯啊！）
但他还是强忍着怒火，回复道：“程经理，我觉得这个设计已经很符合我们的产品定位了，既简洁又实用。颠覆不一定要靠外表，功能才是最重要的。”
场景三：前端程序员的“代码之困”
段码（看到设计稿，也忍不住插嘴，心里OS：吴艾啊吴艾，你这次的设计稿虽然比上次好看了点，但连个交互细节都没有，我这前端程序员怎么写代码啊？难道又要我自己去脑补吗？）
他在群聊里抱怨道：“设计稿里连个交互细节都没有，我怎么写代码？吴艾，你是不是想累死我啊？”
吴艾（听到段码的抱怨，心里更加郁闷，OS：段码，你丫的能不能别这么挑剔？我设计个UI容易吗？交互细节不是要等你们前端来实现的吗？怎么现在反倒怪起我来了？）
但他还是耐心地解释道：“段码，交互细节我会在后续的版本里补充的，这次只是初稿，主要是想让大家先看看整体风格。”
场景四：“吐槽大会”的升级
程立新（不屑地哼了一声，心里OS：吴艾，你每次都是这样，说得好听，但每次都拖拖拉拉的。我这次可是要下狠心了，再不给力，我就换人了！）
他在群聊里威胁道：“吴艾，我给你一周的时间，把设计稿修改到让我满意为止。不然的话，你就准备卷铺盖走人吧！”
吴艾（听到程立新的威胁，心里一惊，OS：卧槽，这程立新来真的了？一周时间？这怎么可能啊？我还要兼顾其他项目呢！这下可怎么办？）
他赶紧回复道：“程经理，一周时间太紧了，能不能再宽限几天？我保证会尽快修改的。”
段码（看到吴艾的窘境，心里暗自得意，OS：哈哈，吴艾，你也有今天啊！不过，我也不能太过分了，毕竟大家都是同事，还是要互相帮忙的。）
他在群聊里打圆场道：“程经理，吴艾也挺不容易的，他最近确实忙。要不我们给他点时间，让他好好修改一下？”
场景五：小老板的“和稀泥”
就在这时，钱多（小公司老板）也加入了群聊，他看了一眼设计稿，然后说道：“大家别吵了，都是为了项目好。吴艾，你尽快修改设计稿，争取让程立新满意。程立新，你也别太苛刻了，给吴艾一点时间。段码，你等设计稿定了再开始写代码，这样效率会更高。”
吴艾（听到钱多的和解之言，心里稍微松了一口气，OS：还是老板明事理啊！不过，这压力还是好大啊，一周时间，我得加班加点了。）
他回复道：“好的，老板，我会尽快修改的。”
程立新（虽然心里还是有些不满，但也不想和老板唱反调，于是也回复道）：“好吧，那就再给吴艾一周时间，希望他能让我看到惊喜。”
段码（看到事情终于有了转机，心里也很高兴，OS：哈哈，这场“吐槽大会”终于要结束了。不过，这周的瓜可真是吃啊，看来创业公司的生活就是这么刺激！）
他在群聊里发了个笑脸表情，然后说道：“那大家加油吧！争取早日让项目上线！”
就这样，第12周的“UI设计稿初稿风波”在钱多的和稀泥下暂时告一段落。吴艾虽然压力山大，但也只能咬咬牙坚持下去。
程立新虽然心里还有些不满，但也决定给吴艾一个机会。段码则在一旁看热闹不嫌事大，期待着接下来的“好戏”。
一些正经话
在软件公司里头，UI评审会是个挺常见的会，虽然不同的公司、不同的项目，组织形式和参会人数可能差挺多，但归根结底，它还是个评审会。评审会嘛，重点就是评价（过程）和审核（结果）。因为研发多数是项目制，这个审核属于工作过程的一部分，得记录在项目管理文件里，算是项目推进的一个重要环节。
那么，组织UI评审会的，自然就是UI设计师了。今天，咱就从UI的角度，唠唠UI评审中可能会遇到的问题，以及咋解决这些问题。
首先，UI评审会得有个UI图作为成果。UI图的输入，通常是产品经理的PRD（产品需求文档）或者页面设计的框架图。UI图作为高保真模型，得在上面添加颜色、尺寸等细节设计，还得给别人讲解，解释为啥要这么设计。讲解的时候，得先“叠个甲”，把一些前提条件说清楚，免得后面被人挑刺儿。
一、会议开始时的“叠甲”
1. 遵循规范
本UI设计遵循了产品设计的UI规范、交互规范，同时参考了前端人员、产品方和用户方的建议，做了PC端、移动端（有几个规格就列举几个规格）的适配。
2. 配色方案
本UI设计遵循了xxx配色方案，实践了多个方案，最终定下此方案进行评审。废弃的方案中，不合适的原因有：
配色对比度过大：视觉效果过于强烈，容易造成视觉疲劳。
配色明暗差较大：明暗对比过于明显，影响用户阅读体验。
配色对某些机型容易烧屏：过亮的配色在某些OLED屏幕上可能导致烧屏问题。
配色对户外作业不友好：过暗的配色在户外使用时，用户难以看清内容。
配色不符合色彩搭配原则：使用色环分析，主要配色的角度并非常见角度（如30°、60°、90°等），属于不推荐配色。
配色无法给出明确提示：布局边界提示不明显，主要操作内容和展示内容区分度不足。
3. 原型基础
本UI设计是在完成产品原型评审的基础上进行的，因此涉及产品原型的内容，不在本次评审范围内。
二、设计讲解
“叠甲”完了，接下来就是讲解设计内容和设计亮点。讲解的重点有以下几个：
1. 布局分类
按照视野的顺序讲解布局，比如顶部、底部、主区域。每个区域的布局逻辑要清晰，用户一眼就能看懂。
2. 组件分类
按照当前页面的功能，将组件按功能分类。尽量把功能相似的组件整合在一个板块里，避免分散。
3. 组件交叉
不同类别的组件出现在同一个板块时，以当前板块的功能为主，对其他组件进行折叠处理。比如表单板块，描述性内容要尽量精简，大段描述如果不是高频或必要，默认折叠。
4. 边界拆分
组件的各个板块之间要有明确的边界或动画效果。在切换板块时，通过明显的动画或边界线、阴影来区分，提升用户体验。
5. 其他细节
比如滚动的细节、点击的细节、板块尺寸的余量、隐藏与展示的动效等。这些细节往往是产品和开发不太会考虑的部分，但却是提升用户体验的关键。
三、设计亮点
设计亮点主要是细节部分，尤其是那些产品和开发通常不会考虑的地方。虽然这些细节可能会增加他们的工作量，但对用户体验的提升是实实在在的。比如：
滚动的细节：如何让滚动更流畅、更符合用户预期。
点击的细节：按钮的点击反馈是否及时、明显。
板块尺寸余量：确保不同设备上显示效果一致。
隐藏与展示的动效：通过动画提升交互的趣味性和直观性。
非标准设计内容：比如某个元素不是横平竖直的，这种非标设计如何与整体风格协调。
四、再次“叠甲”
讲解完设计后，还得再“叠个甲”。既然是评审会，肯定会有别人的评价。对于这些评价，如果是用户要求，咱可以考虑修改；如果不是用户要求，咱不一定非得遵守。对于设计错误，比如文字错误、同类内容设计不一致的地方，欢迎提出。但涉及到UI规范的部分，本次评审不做讨论和更改。
五、UI评审中的难处
UI评审的难处在于，谁都能评价，谁都能说几句。但作为UI设计师，咱得让其他非专业人员明白，UI设计是个客观性很强的职业，不是凭感觉来的。尤其是涉及到颜色搭配时，得用数据和理论说话。
比如颜色搭配，可以分为以下几种情况：
1. 色块相邻
2. 色块相离
3. 色块相交
4. 色线相邻
5. 色线相交
6. 色线相离
每种情况都得有个色环角度的搭配示例，比如以30度为基准，做好搭配示例的卡片，再调整饱和度、明暗度，形成一个完整的色彩搭配矩阵。这个矩阵展示出来可能会让人头疼，但咱得明确指出，当前设计使用的是哪种搭配方案，可以修改的范围是哪些，哪些是不可选的。
比如：板块分类的合理性
对于板块分类是否合理，咱可以直接说，这是遵循了产品设计要求。如果有人认为需要修改，那得倒回去重新评审产品原型设计。也就是说，对于不属于UI评审的内容，咱得顶回去，这不是UI的工作范畴。
六、总结
UI评审会是个需要技巧的活儿。作为UI设计师，咱得提前“叠甲”，把设计依据和规范说清楚，避免被人挑刺儿。讲解设计时，重点突出布局、组件、边界等细节，尤其是那些产品和开发不太会考虑的亮点。最后，对于非UI范畴的修改建议，咱得明确顶回去，确保评审会的效率和质量。
通过这种方式，咱不仅能有效推进UI评审会，还能让其他团队成员明白，UI设计是个有章可循、客观性很强的职业，不是凭感觉来的。