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

推荐订阅源

V
Visual Studio Blog
Recent Announcements
Recent Announcements
有赞技术团队
有赞技术团队
The GitHub Blog
The GitHub Blog
N
Netflix TechBlog - Medium
腾讯CDC
A
About on SuperTechFans
博客园 - 叶小钗
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
D
DataBreaches.Net
D
Docker
宝玉的分享
宝玉的分享
量子位
Microsoft Azure Blog
Microsoft Azure Blog
Martin Fowler
Martin Fowler
博客园 - 三生石上(FineUI控件)
Jina AI
Jina AI
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
V2EX
Last Week in AI
Last Week in AI
H
Help Net Security
Hugging Face - Blog
Hugging Face - Blog
M
MIT News - Artificial intelligence

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
交互细节——管理模式下是否需要确认按钮?
阿青 · 2023-08-11 · via 人人都是产品经理

关于“管理模式下是否需要确认按钮”这一问题,作者结合自己最近的一次设计方案复盘,从三个维度展开分析,希望对你有所启发。

对于最近设计方案的一次复盘。本文主要关于管理模式的部分。

背景

需求:在课程章节页面,老师希望可以对章节、单元编辑名称和调整顺序。

设计问题:

  1. 操作功能入口放在哪里?
  2. 是实时保存同步,还是点击确认按钮保存同步?
  3. 树结构下的排序如何设计?

一、操作功能入口放在哪里?

最开始想到的就是放在章节单元后,增加更多 icon,用户点击更多进行章节单元的编辑删除,拖拽直接调整排序。可是这种设计方式让章节看起来复杂很多,而且老师使用频率很低,一般只有在学期刚开始,备课时设置,后期几乎不再会进行调整。

为了降低页面复杂度,我把编辑排序放在统一入口,点击后,再进行操作。我给这个入口命名为管理。点击管理,进入到管理模式,调整章节、单元的名称和层级结构。

二、是实时保存同步,还是点击确认按钮保存同步?

1. 实时保存

实时保存就是用户的每一步操作都会立即生效。比如一些标题的编辑,鼠标hover上去会展示输入框,光标消失即保存成功。或者知乎编辑文章时,也会告诉你保存中。

实时保存相较于确认保存少一步操作路径,每一步操作立即生效同步更新,相对来说效率较高。由于人们总是会忘记收尾工作,实时保存也避免了让用户承担忘记点击确认按钮而使数据丢失的风险。

实时保存也有缺点,比如当用户想要反悔撤销的话,就会比较困难。一般会根据具体需求搭配撤销按钮、历史版本等方式,给用户一个反悔撤销的机会。

2. 确认按钮保存

用户进行的一系列操作,都不会立即生效,而需点击确认(保存等)按钮后,所有操作才会生效。比如飞书管理后台对于会议室预约规则的设置。默认是查看模式,修改字段进入编辑模式,展示取消、保存按钮,点击保存更新修改,取消则回到编辑前的状态。

这种方式的好处是,减少用户修改过程的心理压力。用户在修改过程中可以随意调整,内容不会被同步,修改好后点击确认按钮统一保存,内容同步。

为什么用户在编辑时会有心理压力?重点就在于同步给谁,以及同步的内容是什么。

3. 用户

内容修改后只同步给自己。

例如微信标签管理,进入管理模式后,对于标签的排序,删除都实时保存更新,没有确认按钮。标签修改后的结果只会同步给自己,而自己在管理标签的过程已经知道了修改结果,如果增加确认按钮倒显得较为繁琐。

内容修改后会同步给其他用户。

例如飞书管理后台对于会议室预约规则的设置,设置结果会影响其他用户预约会议室,比如能不能约、几点能约,所以同步设置结果就必须要谨慎一些。而多一步确认(保存)按钮可以帮用户再次确认自己的操作行为,让同步结果更谨慎。

以上可以总结为,如果内容修改后只同步给自己,则实时保持更便捷。如果内容修改后会同步给其他用户,则需考虑增加确认按钮让操作行为更谨慎。具体还需考虑内容本身。

4. 内容

如果内容对其他用户影响不大,也可以使用实时更新。

比如飞书管理后台对于会议室名称的修改,修改后,光标移开即保存成功。会议室名称对于用户来说只有信息的传递,没有功能上的制约,甚至也不影响用户行为目标。可以思考下,当用户想约会议室时,什么会影响用户决策?比如位置-用户会考虑距离是否合适、或者状态-是否当前被占用等,但会议室名称几乎不会影响用户预约决策。所以内容对用户影响较小,使用实时更新。

编辑者对于内容的重视程度。

比如知乎内容发布后,二次编辑,需点击保存更新才会同步给其他人。创作者写文章耗费了自己的时间成本,好的内容可以帮创作者带来流量和价值感,所以创作者会更重视文章内容的完整性。而实时同步编辑过程所展示的内容是不完整的,会影响读者阅读内容的感受。所以点击保存更新,统一同步内容可以避免这些问题的发生。

三、我的方案

回到自己的产品上,老师对于章节的管理操作会同步给学生,调整结果会影响学生查看章节结构。作为学生,主要任务是完成章节或者单元下的学习活动。所以调整的内容并不影响学生完成学习任务,按照我们所总结的规则,内容对于同步者影响不大,可以使用实时更新。

再来看编辑者对于内容的重视程度。老师会在学期前开始备课,管理层级结构属于备课环节,教学内容一般都是固定的,所以后期调整层级结构的频率很低。操作行为低频且优先级不高,内容固定,对于老师来说,重视程度一般。所以也可采用实时更新。

由于老师编辑章节或单元已有保存按钮,如果管理模式还存在保存操作的话,对于编辑功能来说需 2 次保存才算是真的保存,理解成本过高。选择实时保存方式更合适。

根据以上 3 点,我的方案选择实时保存,实时更新。

最后

以上是我对于工作内容中关于管理模式的复盘思考,最终设计方案的产出还是需要结合自己产品的业务,在体验和功能的权衡之下做出最合理的设计。

关于第三部分排序放在下次在写….

本文由 @阿青 原创发布于人人都是产品经理。未经许可,禁止转载

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。