惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Hugging Face - Blog
Hugging Face - Blog
云风的 BLOG
云风的 BLOG
大猫的无限游戏
大猫的无限游戏
M
MIT News - Artificial intelligence
L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Recent Announcements
Recent Announcements
IT之家
IT之家
Google DeepMind News
Google DeepMind News
罗磊的独立博客
爱范儿
爱范儿
Last Week in AI
Last Week in AI
人人都是产品经理
人人都是产品经理
U
Unit 42
MongoDB | Blog
MongoDB | Blog
S
SegmentFault 最新的问题
B
Blog
博客园 - 叶小钗
月光博客
月光博客
Stack Overflow Blog
Stack Overflow Blog
V
Visual Studio Blog
C
Check Point Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
UI/UX设计师用“5段式逻辑法”汇报方案,从“被质疑”到“被夸专业”
知果日记 · 2026-04-14 · via 人人都是产品经理

还在为设计方案在评审会上被各种质疑而头疼吗?其实问题可能不在于设计本身,而在于汇报的逻辑。从‘被质疑’到‘被夸专业’,可能只需要换一种表达方式。本文将深入解析一套经过验证的‘5段式逻辑法’,教你如何通过清晰的价值阐述、明确的目标设定、细致的拆解分析以及有力的数据佐证,构建一套无懈可击的汇报逻辑,从而赢得评审者的认可。

不知道你有没有遇到过和她一样的情况,我暂且称呼她为小丽吧,她遇到了一个问题,来问我,说:“知果老师,我最近优化了一些目前支持的产品上的界面体验设计方案。但我拿着方案去评审的时候,被一些同事问了很多问题,比如为什么这个交互这样子做?你有没有考虑到那个场景?为什么这颜色这么奇怪?等等。我被他们问的不知如何是好,我应该怎么才能让大家最大程度接受我的方案呢?”

其实她这个问题,在我还是一名初级设计师的时候也会遇到。而且一度让我在每次进行界面设计方案评审或汇报的时候感觉到头疼,因为,大家又要围着我问一大堆我回答不上来的问题了,这导致我抵触去汇报自己的设计方案。

记得有一次评审会,会上来了一名很喜欢钻研“究竟”的前端同学,他卯着劲问我,这些设计方案遵循了XXX、XXX、XXX法则没,比如有没有遵循黄金分割法则、格式塔原理、排版四大原则等,你要是回答不上来,他就觉得你没好好思考,没有好好设计。

你说,去这样子的评审会,你紧张不紧张,反正我是很紧张的。

后来,参与评审会多了(被评审者与评审者),并且直接向决策者汇报方案的次数多了,我也慢慢积累了一些方法。这些方法不一定适用所有场景,但当你没有思路的时候,不妨试试。

下面开始咯,我称之它为“5段式逻辑法”。

1、为什么要做(即价值在哪里)

2、目标是什么(即要解决什么问题)

3、从哪些方面解决(即解决范围)

4、如何解决(即用哪些方法解决)

5、结果怎么样(即最终效果如何,是否达成目标)

01 为什么要做

无论多小的B端界面体验设计方案,最好我们都能对“为什么要做”做到心中有数。比如,界面上某个图标要优化:是因为它不好看呢,还是因为目前的它无法明确向用户传达其特定的含义;是产品经理自己提出来的呢,还是用户反馈的;是一个用户反馈的呢,还是多个用户都这么反馈。

只有我们明白了我们为什么要做,我们在做的时候才能胸有成竹。

举个例子:

小A和大A对同一任务的不同处理方式,我们来看看谁的让人感觉更好。

领导给他们分别布置了一个任务,把当前系统的默认主题色进行一下优化,给了他们2天时间。

小A领到任务觉得太简单了,把现在的主题色换个颜色多简单,选几个好看的颜色就行,2天时间足够了,甚至时间还很多。做完后,让领导选选哪个好看,任务很容易就完成了。

大A不这么想,他思考,为什么领导忽然想要把系统默认主题色优化,现在的主题色是哪里不好,改成什么会更合适…他整理了一些问题,来到领导这里,准备将这些问题解决后再开始做。他知道,只有将这些疑问弄清楚,才合适动手做。

那么,后面谁的界面设计方案会让评审者认为更加合理呢?我想,一定是大A,至少他在工作态度上,就已经赢了,即便方案不够完美,回去二次优化即可。

02 目标是什么

一旦我们了解了本次界面设计优化是为什么,我们就要设定优化目标了,也就是优化到何种程度,才算是达到了优化的意义。

以上面说的,领导想要把系统默认主题色优化为例。是不是说,我们将现在的蓝色优化为红色就是优化了呢?或者给出几个优化方案,让大家凭喜好选一个?

当然不是,我们需要给优化定一个目标。比如,将默认主题色由蓝色改为红色后,在上线前经过用户测试,是否被更多用户认可了。再以流程优化为例。比如原有流程用户完成,平均需要3分钟,优化后要达到2分30秒以内,如果设计达到了,那么就是优化的目标一部分完成了(还需要看交互是否符合用户操作习惯等);若设计后,用户依然需要3分钟才能走完该流程,就是没有完成目标。

因此,我们在做界面体验优化前,需要尽可能知晓体验优化的目标是什么,如此才能在落实设计方案的时候,更有针对性。

03 从哪些方面解决

明确了为什么要优化以及优化目标后,我们就要拆解优化范围了。

我以图标视觉优化和单选选择器组件交互优化为例,简单展开说说。

一、图标视觉优化。

如果是图标视觉优化,我们可以拆分为视觉优化的一些点,比如尺寸大小、线条粗细、颜色、造型。相当于我们需要先弄清楚图标是有哪些视觉元素组成的,然后将这些维度逐一列出来,涉及到无需修改的视觉,我们可以划掉,涉及到可以优化的视觉,就保留下来,然后慢慢优化。好比图标尺寸大小、颜色无需优化,那么我们可以不考虑这两点。

二、单选选择器组件交互优化。

如果是单选选择器组件交互优化,我们可以想下,构成单选选择器组件交互的要素有哪些,比如我能想到的一级层次是鼠标交互和快捷键交互。二级层次是,在鼠标交互下包括鼠标hover、鼠标点击、鼠标选择选项等交互要素;在快捷键交互下包括键盘键进入组件、键盘键唤出下拉面板、键盘键选择选项等交互要素。总之,尽可能将涉及到的交互要素拆解得细,然后逐一去考虑。

将优化点按照一定的规则拆解为具体可优化的要素时,我们可以比较简单的发现问题,从而解决问题。如果我们不能够拆解清晰,或拆解有误,也就能难找到方法来破题。

04 如何解决

在第三点中,我们已经用了一些方法将需要优化的点进行了拆解,在第四部分,我们去逐一解决就好。

解决的过程中,一定会出现一些困难,如果可以,最好将一些确实被大家也认可的难点写到方案中,并讲讲自己的解决思路;如果还可以更进一步,可以形成自己的方法论,给到评审者。这会让他们觉得,你不是一个纯粹的执行者,而是一个思考者。

谁会吝啬给思考者一个赞扬呢,我想,不会有人吝啬的,他们欢迎还来不及呢。

在若干年以前,我负责B端官网首页的视觉设计时(我给出了两个方案),为了让大家知道这两个方案的优劣,及我的设计思考和采用的设计方法,我将它们一一梳理了出来,并还在最后给出了自己的建议。因此评审过程较为顺利,二选一后,在被选中的方案上面继续进行优化。

在评审会上给出自己的解决思路和解决路径,远远比只给出一个纯粹的设计结果来的更加有说服力和感染力。有时候,这可以让评审者看出我们平时在处理工作上的态度和想法。如此几次以后,你再进行评审会,大家都会对你更加友好,因为他们相信你的专业能力。

05 结果怎么样

通常情况下,我们会放一个设计结果在ppt上,要么占据一页,要么两三页,但基本只是效果图。

虽说这样子问题也不大,但距离有说服力还是有点差距的。

我们可以尝试这么改一下:ppt的左边是原有效果,ppt的右边是现有方案。然后谈下用户测试的结果如何,来证明现有方案确实比原来方案好了。如果找不到用户,那我们可以讲讲方案在组织内部相关同学看了后怎么样了。

总之,我们需要用一些方法来给证明当前设计方案优于原有方案,或者是达到目标的原因。这些原因不是自己想当然认为的,而是有数据佐证的。

06 最后的话

如果你还担心评审会上,你的界面设计方案会被评审者提出这样子或那样子的问题,不妨试试“5段式逻辑法”。

然后你在再根据组织、团队、评审者的特定情况,进行对应调整。

不过,即使我们感觉自己在评审会前已经准备的很充分了,我们依然可能遇到突发情况。

比如会议上来了一个喜欢抬杠的同学,比如有个同学临时被通知参加的(他问了很多本该会前解决的问题),比如领导今天正好心情不太好,等等。

不过没关系,经历的多了,你会找到一些自己的方案来应付这些局面。

我始终相信,只要有心想把一件事做好,全世界都会为你让路的。

本文由人人都是产品经理作者【知果日记】,微信公众号:【知果日记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。