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

推荐订阅源

Forbes - Security
Forbes - Security
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
P
Palo Alto Networks Blog
Martin Fowler
Martin Fowler
T
Threatpost
D
Docker
S
Schneier on Security
M
MIT News - Artificial intelligence
G
Google Developers Blog
L
LINUX DO - 热门话题
J
Java Code Geeks
月光博客
月光博客
博客园 - 三生石上(FineUI控件)
IT之家
IT之家
博客园 - Franky
C
Cyber Attacks, Cyber Crime and Cyber Security
K
Kaspersky official blog
Google DeepMind News
Google DeepMind News
N
News and Events Feed by Topic
V
Vulnerabilities – Threatpost
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
人人都是产品经理
人人都是产品经理
Spread Privacy
Spread Privacy
T
Tailwind CSS Blog
爱范儿
爱范儿
阮一峰的网络日志
阮一峰的网络日志
U
Unit 42
C
CERT Recently Published Vulnerability Notes
The GitHub Blog
The GitHub Blog
Simon Willison's Weblog
Simon Willison's Weblog
NISL@THU
NISL@THU
MongoDB | Blog
MongoDB | Blog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
H
Heimdal Security Blog
Recorded Future
Recorded Future
云风的 BLOG
云风的 BLOG
SecWiki News
SecWiki News
P
Privacy International News Feed
P
Proofpoint News Feed
O
OpenAI News
B
Blog
腾讯CDC
F
Full Disclosure
Apple Machine Learning Research
Apple Machine Learning Research
T
Tor Project blog
H
Hacker News: Front Page
Project Zero
Project Zero
Hugging Face - Blog
Hugging Face - Blog
C
Cisco Blogs
S
Security Affairs

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
以小鹅通为例,探讨SaaS产品如何解决“上手难、效率低”的用户体验问题
B端编外产品 · 2023-03-17 · via 人人都是产品经理

大部分SaaS产品发展到一定阶段后,功能都会变得复杂,初期忽略的问题开始显现,变成SaaS产品发展的沉重“包袱”。本文作者以小鹅通为例,分析如何解决“初期上手难,中后期效率低”的用户体验问题,希望能给你带来一些帮助。

大部分SaaS产品发展到一定阶段后,功能都会变得很复杂,那些在初期被忽略的产品设计问题,此时开始显露出来,用户体验问题不断增多,产品易用性下降、用户成本增高,最终变成SaaS产品发展的沉重“包袱”。目前,市面上越来越多的SaaS产品都遇到了这样的问题,开始重视起产品的用户体验。

其实,各SaaS产品的用户体验问题是相似的——【初期上手难、中后期效率低】。但是,如何解决这些问题呢?是否有通用的解决方案?笔者作为B端产品经理,希望通过对个例的分析,探究SaaS产品共通的产品设计方法论。

一、开篇概述

本篇文章以小鹅通为例,代入普通用户视角下,对一个SaaS产品【从接触、到初步使用、到串联运营、再到长期管理】的完整使用过程,观察SaaS产品的用户体验问题,分析得出SaaS的产品设计逻辑和通用解决方案。

二、体验产品介绍

小鹅通是一个标准化SaaS产品,让用户快速拥有一个专业完整、可运营的线上知识店铺。

小鹅通的核心功能,包括直播、圈子、内容课程、助学互动工具、CRM、企微助手、营销活动工具、推广员裂变等。产品覆盖了对一个线上知识店铺全方位、全流程的运营:从搭建、到公/私域引流、到交易转化、到内容交付、到私域内留存维护、到复购、到裂变······

据公开信息显示,截至2022年12月16日,小鹅通累计终端用户数(去重)已达8.2亿,最高日活达1400万,分布在全球564个城市,其中中国有322个城市。C端用户累计学习时长14亿个小时,平台客户累计创造知识商品数4226万个、累计开播直播数256万场。

由于小鹅通后台功能丰富,覆盖了完整的业务场景与流程,其后台功能的复杂度也很高,一定程度上增加了用户成本,很考验SaaS产品设计时的多方面思考与平衡,适合作为SaaS产品设计分析的典型案例

三、体验情况

笔者代入一个小鹅通典型用户(想搭建一个知识店铺,并长期运营知识内容IP)的视角,体验“我”(即B端用户)在使用小鹅通SaaS产品、使用后台某个具体功能过程中的感受,共包括四大步。

1. 找到我需要的功能

作为一个新用户,我已经有一个知识店铺的想法雏形,想用小鹅通实现,但是在要动手落实时,我有些迷惑。

1)面对这么复杂的后台功能,我应该用哪些,按什么步骤,才能完成“搭建一个知识店铺”的大任务 ?

大部分SaaS产品的后台导航栏,都是按抽象层业务场景分类的,并且平铺展示所有分类和分类下所有功能,以便日常使用时,用户可以按常规的场景分类逻辑找到目标功能。

但这意味着新用户进入后台后,面对的功能架构是无顺序、无重点的,他们很难快速发掘出哪些功能对他们有价值,哪些要现在使用、哪些可以后期再延展考虑。并且,不同商家解决这个问题的难度不同:

  • 需要了解的功能范围不同:不同行业、不同业务模式、不同运营目的……
  • 学习教育成本不同:是否在线上/线下做过知识课程行业、是否用过其他SaaS产品、是个人还是团队……

2)有好几个功能很相似,似乎都能达到我的目的,但它们的区别是什么?哪种最适合我的情况呢?

针对某一宽泛且重要的场景,SaaS产品常常会提供多个细分方向的功能。

但在新用户看来,它们是极其相似的,他是需要再次”做决策“的,如果此时还没有通过产品设计展示清楚它们的场景/功能的核心差异点,即用户的决策点,用户使用的心理门槛一定会被提高。

小鹅通案例:

① 系列内容交付场景下,用户会看到训练营pro、训练营、专栏、大专栏、会员、圈子等功能;

② 打卡场景:日历打卡、作业打卡、闯关打卡;

③ 测验场景:考试、练习、作业本、测试互动;

④ 营销场景:通用优惠券、专属优惠券、员工优惠券。

第一部分小节:

1)设计反思

【找到我需要的功能】过程中的体验问题,非常基础且重要,因此,目前小鹅通更多是通过【新手商家训练营、售后服务群、试用全流程专人辅导】的方式解决掉的,大部分SaaS厂商都是类似的方式。但我们作为产品设计者,也要将视角从自己负责的单一功能挪到SaaS产品的整体系统上,思考更好的解决方案。

2)通用解决方案思考

在应用广场内,以【功能画布】的形式,展示后台大大小小的功能应用。【功能画布】是指:

  1. 按实际的【业务场景】对功能进行分类,并按实际的【业务流程】的顺序,展示【业务场景】及其下功能;
  2. 每个功能下展示其功能内容、适用场景的介绍(尤其需要写明相似功能间区别)。

形式逻辑参考商业画布、业务流程图、获客-运营-成交3步曲等商业运营模型;

内容思路参考该SaaS产品的典型客户行业的运营模式,例如小鹅通可参考知识店铺、知识IP、企业培训的运营模式。并且可针对不同用户画像(不同行业、不同业务模式等)、不同重要运营场景(用户运营、成交转化等)、不同业务流(上架一个知识商品、开始一场对外直播),提供对应的【功能画布】。

【功能画布】让新用户能快速get后台中每个功能与他实际业务间的对应关系,最终达到帮助用户快速熟悉&建立认知的目的,为用户上手整个产品做好铺垫。

2. 第一次尝试使用一款功能

当我找到目标业务功能时,为了确认它到底能否实现我要的效果,一般会进行一次创建,并查看创建后成果。

但很多业务功能创建过程的学习、理解和使用成本都比较高,我经常无法顺利完成创建。

1)这几个功能到底是什么关系?没有题库题目/试卷,就无法有考试吗?

有时,业务的流程非常长、或者某一步业务可以被多个业务使用,对此类情况,SaaS产品通常会选择拆分成多个“独立”功能,以减轻日常使用的负担、简化底层逻辑。

但实际上,用户的完整使用路径仍然是——用了B功能才能正常使用A功能。且B功能只是过渡,用户的最终目的是A功能。

如果,像这样使用流程/业务流程有十分清晰从属关系的两个功能,不在一个板块下展示、也没有将这种流程/关系清晰地呈现在任何一边功能上。用户将未无法从界面设计、功能流程上,直观地发现A、B功能之间存在关系,这会造成2种用户体验问题:

  1. 用户使用A功能时,中途发现需要使用B功能,只能重新来过;
  2. 用户看到B功能,但不知道如何达到自己的最终目的;

最后,用户只能在几个功能下不断使用,不断思考,靠自己摸索出来。

小鹅通案例:

① 考试、试卷、题库

  • 用户想用考试功能:在考试编辑页发现需要先有试卷,到试卷又发现需要先有题库题目,来回反复几次,商家才弄清考试、试卷、题库这三者的关系。
  • 用户看到了题库/试卷功能,却不知道怎么获得一个考试并分享学员,甚至不确认是否有考试类功能。

② 运营计划、用户分群、用户标签

2)这些设置项是什么意思?控制什么的?

设置项难以理解,通常都是产品表达有问题,造成各种各样的理解问题,导致用户学习成本很高。设置项的产品表达问题一般分为2大类、5小类情况。

小鹅通案例(设置项体验案例较多、图示较长,可跳跃查看):

案例1:所属组合课是什么意思?是专栏的添加课程?还是训练营pro的关联?对我创建这个视频课有什么影响吗?

案例2:小鹅通考练测评工具(考试、练习、作业、随堂测试)虽然细节有所不同,实际上都可总结为:填写基础信息+编辑一份题+设置填写规则,但是它们的创建页呈现截然不同的界面设计。

  • 创建考试是,分步分页式,顺序为基础信息→关联课程→信息采集→规则→内容(展示引用内容明细)→发布设置;

  • 创建练习是,一步单页式,顺序为基础信息→内容(不展示引用内容明细)→规则→商品→引流→信息采集;

案例3:创建课程时,“商品信息”中“是否单独售卖”的勾选项,解释为:勾选支持后“客户可以通过店铺或链接的方式单独购买该商品”。

案例4:创建练习时,“练习设置-答题设置”的选项为随机出题/顺序出题。

案例5:日历打卡创建页的设置项分类。

3)要上架一个系列课和下面所有单课,需要做的准备工作好多啊。

SaaS产品的核心业务场景,通常比较复杂,会涉及多个功能,这种使用成本是无法避免的。

但长流程、多功能的背景下,如果团队内部没有注意在每一处功能下拉通考虑全流程/上下流程的功能情况,就常常会造成一些增加用户准备工作的产品设计问题。

小鹅通案例:

要成功创建并在店铺上展示一个内容,需要提前准备各种尺寸的图片

① 为适配在店铺内不同位置、不同组件的展示,同一内容需要准备很多尺寸的图片:视频的贴片、封面;

② 店铺内相同位置类型的展示,不同内容类型需要准备不同尺寸的图片:视频、训练营pro的封面。

第二部分小节:

1)设计反思

【第一次尝试使用一款功能】过程中的体验问题,非常细碎且难以解释,会阻塞用户使用,是用户面对新功能时“战战兢兢”的元凶。而且,每个业务功能或多或少都有,导致产品难上手、服务教学效率低、用户易流失,是需要尽快优化的。

同时,这类问题大部分都是纯粹的产品设计问题,可以通过优化解决掉,仅有少量涉及底层业务逻辑。

2)通用解决方案思考

梳理现有功能,找出使用流程/业务流程有先后关系的功能们,模拟当前可能出现的用户使用路径,找到易中断、不流畅的节点,通过优化它们的设计(功能入口/创建流程/管理界面/跳转入口),优化使用体验。

重新观察核心业务的创建功能,通过找小白试用等方式,找到其中难以理解、难成功的点,进行整体优化。

检查功能之间产品表达的不一致点,核心关注① 关联两个业务的功能,② 在多个业务下都存在的功能/设置项/字段,由业务所属方统一表达,修改在其他业务下的表达,并形成产品层面的规范文档,供后续迭代参照、维护。

代入用户最终的业务目的,多去全流程体验,从全局视角观察用户体验,最后再去反观当前这个功能有什么产品设计问题、可以从哪个地方入手解决(有可能是从其他功能和环节入手)。

3. 串联多个功能,完善对主业务的运营

小鹅通后台中,想要运营主业务(如视频),就需要用到很多辅助业务(如考试、优惠券),通常是通过建立“关联”关系的方式,将辅助业务补充到主业务下。

“关联”功能逻辑的设计,本来是为了简化各业务管理范围,提高用户管理效率。但目前,主业务下辅助业务展示与管理的设计存在一些问题,反而提高了用户成本。

1)老客:我们之前一直在运营这个课程,给它增加了营销活动、还设置了课堂互动,现在我想看看这个课程表现如何,但我也记不清我到底给它关联过什么东西了——主业务下没有展示辅助业务。

之前,用户为主业务做运营时,在其他辅助业务侧创建了一些东西,并”关联“到主业务上,但是时间一长,用户自己也记不清了。

这些关联关系靠用户自己记忆是极其低效的,很容易导致管理运营上出现遗留。实际上,用户的日常运营是从某个主业务对象出发的,SaaS产品应该依靠功能,当该主业务的详情页展示出与之相关的各种辅助业务(名称、入口),这同时也能帮助商家明确【C端在接触这个课程时能感受到什么】。

小鹅通案例:

① 给一个课程关联考试、打卡、表单等:课程下无展示,考试下不能搜索课程。

② 给一个课程设置秒杀、优惠券等:课程下无展示,秒杀下不能搜索课程。

2)新客:我第一次试用小鹅通的内容功能,例如视频,但主界面上看到了很多不了解的功能,是否必须使用?——主业务下辅助业务展示的时机和位置不恰当 。

主业务下需要展示相关辅助业务,但如果展示和管理方式的设计不合理,就会对新用户造成较大认知负担

①主业务的创建流程中夹杂辅助业务的功能设置

  • 如果新用户之前没有接触过那个业务,理解成本瞬间double;
  • 会大大增加主业务的创建流程,并且会受到辅助业务的逻辑限制,导致主业务创建/修改失败,而且还不知道原因,用户难以规避、产研难以修复。

②在主业务的核心界面/默认界面中,直接显示和管理辅助业务

  • 新用户刚创建完主业务对象,准备使用一下,就看见了很多新东西;
  • 通过插入辅助业务管理板块的形式,直接管理“关联”关系,容易让用户错误理解本次管理的影响范围(对比跳转形式、弹窗形式),同时导致用户忽略辅助业务中其他设置项的影响。

小鹅通案例:

① 访问单品课详情页默认选中运营设置,里面展示超级会员、信息采集的辅助功能;

② 创建日历打卡会遇到“关联超级会员卡”;

③ 创建考试会遇到“关联课程”、“信息采集”;

④ 创建表单会遇到“引流设置”。

第三部分小节:

1)设计反思

【串联多个功能,完善对主业务的运营】过程中的体验问题,问题表象众多,但本质问题是类似的——是否应该在主业务下提供辅助业务的展示和管理入口?如果需要,那具体形式应该如何?

  • 需要提供入口:保障用户的管理效率与便捷体验;
  • 需要优化和统一形式:通过产品表达,帮助① 让老用户明晰主业务与辅助业务的边界、明晰修改影响的范围;② 降低新用户的认知负担。

2)通用解决方案思考:

  1. 梳理并定位清楚,产品中有哪些主业务,每个主业务支持哪些辅助业务;
  2. 对主业务下辅助业务的展示形式和管理形式,统一出一种产品设计规范,任何辅助业务在任何主业务下都遵守该规范的大原则;
  3. 设计“一个主业务下有很多辅助业务”时,所有辅助业务入口集中展示的方案。

4. 长期管理一个业务/一个功能

我的业务不断沉淀、不断增长,每个功能与其他功能的联动也越来越多,人脑在这时候败下阵来,效率明显变慢,必须得寻求专门的管理功能来协助了。但开始长期管理了,我才发现针对B端管理场景的功能并不多。

1)各业务侧下,帮助我快捷管理大批量业务对象的功能不多,我的管理效率提升不多。

大部分SaaS产品中,用户在该产品的核心业务下都有几百上千个业务对象(用户表的量级更大),并且因为业务的复杂性,很多业务数据表都是联表——底层涉及多张不同的独立业务数据表。因此,各核心业务管理列表下,快捷管理类功能(筛选、搜索、排序、分组管理、批量操作)的迭代,总会受到技术成本、实现难度等客观原因的限制。

目前,快捷管理类功能的缺失,导致用户的管理效率不高、体验不佳,往往只能自己在本地解决管理B端管理需求:

  1. 查找场景:靠导出列表后在线下处理
  2. 管理场景:靠在线下再管理一份
  3. 运营操作场景:靠人工对每一个业务对象一次一次反复操作

虽说“客观限制”很多,但我们仍然需要代入反思一下,如果在自己的工作中没有了这些功能,使用会有多么麻烦、体验会有多么难受?更何况是在一个多人协作管理的SaaS产品系统中。

企微、腾讯文档假设案例:

  • 没有文件夹功能/标签功能,所有文件按固定规则平铺在一层,虽然有创建时间、文件大小字段,但不支持按这些字段排序;
  • 搜索文件只能进入该文件所在文件夹后,再搜索,不能在顶层直接搜索;
  • 企微中搜索人名、群名、聊天记录,要到3个地方搜索;
  • 在企微群聊里,不能按人/时间/内容类型/具体内容,筛选聊天记录。

小鹅通案例:

① 课程商品没有全局列表/全局搜索功能:

② 找一个不知类型的课程:到每类课程管理列表下搜一遍;

③ 找一个训练营营期:打开每个训练营的详情页看一遍下属营期。

④ 在某个课程的学员详情列表中,找学习时长不达标的学员、找某个知道昵称的学员:自己导出列表数据,在本地排序、筛选;

第四部分小节:

1)设计反思

【长期管理一个业务/一个功能】过程中的体验问题,更接近在深度管理场景下提高B端效率的新需求,很多SaaS产品的用户反馈中不少都是这类体验问题。

并且,与学习成本高导致的体验类问题不同,这类问题是用户业务达到一定量级后必然出现的,所以也非常容易被吐槽,但如果做好了也会是对管理效率场景的重要提高,会成为产品的竞争力。

不过,这类需求通常也面临着实现成本、技术难度的问题,需要综合考量。

2)通用解决方案思考

以B端管理场景为核心,汇总抽象各业务侧相关需求,分析每个需求对用户效率与体验的影响程度,综合判断出需要整体提供的、需要单独提供的、可以通过其他方式解决的、可以暂缓不解决的。

通过新的产品规划+技术优化,提供B端管理场景用户效率与体验的重点功能。

四、总结

这次以用户视角体验SaaS产品的产品设计,带给我最大的感受是:

1)SaaS产品”初期上手难、中后期效率低“的用户体验问题,是可以通过产品设计解决或优化。

2)用户体验无小事,用户体验最终影响的是SaaS产品的产品价值,SaaS产品的团队一定要重视并着手优化用户体验。

对SaaS产品的设计者来说随意一次不顺手的体验、一个不清晰的表达,放在客户身上就是长久的忍耐力考验大赛。

SaaS产品通过产品功能向客户交付自己的产品价值,客户通过产品功能实现自己的业务价值。但是,SaaS产品的交付、客户的实现都是需要付出成本的,如果这个成本(培训客户、上手使用)过高,就会不断抵消其带来的价值。因此,用户体验看似只影响过程感受而非最后成果,实则影响的是客户实现价值前需要投入的成本,影响是SaaS产品的客户价值,即产品价值。

本文由 @B端编外产品 原创发布于人人都是产品经理,未经许可,禁止转载

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

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