漫谈2B SaaS – 从5个方面,做好产品设计

0 评论 1711 浏览 9 收藏 21 分钟

这篇文章里,作者从评价标准、设计风格、企业的产品原则、设计原则、设计工具等方面,分享了自己关于To B SaaS产品设计的理念和方法,一起来看看吧。

各领域里好的产品,都有其共通性,因此像《产品心理学》这种经典,对各领域产品设计者都有很大帮助。但每个种类的产品,当然也有其特别性。2B SaaS的产品设计,会有很多不同于其他类型产品的设计原则和方法。2B的重点是面向特定的企业领域,提供特别的业务价值和效率体验;SaaS是产品交付形态,更是商业模式,因此SaaS产品要支持产品价值交付的低成本高效率好体验,同时要支持SaaS这种商业模式所需要的商业体验。

我想从评价标准、设计风格、企业的产品原则、设计原则、设计工具这几个方面,分享一下我对2B SaaS产品设计的理念和方法。

一、产品评价

要做好产品,首先需要确定一个标准,做成什么样子就算好产品。这有2个视角来评价,一个是从设计角度看2B产品要设计成什么样子,另一个是从客户角度如何评价产品并因此决定是否购买产品。

首先是设计评价。我有个评价模型,2B SaaS产品可以从4个层次来看:有用、好用、优雅、关怀。

  • 有用, 在确定的问题域里,清晰理解场景,提供高效率的解决方案,使用户和客户都获得真实有效的价值。
  • 好用, 产品是否内部逻辑清晰,交互合理,对外与企业已有和将有工具和流程共同协作,明显改善企业用户的业务效率和工作体验。
  • 优雅,产品是否给用户带来愉悦感、控制力、安全感。是否给客户企业带来低风险、高效率、低成本的价值展现能力。
  • 关怀,产品是否关心用户的工作体验和成长,给用户带来获得感、成就感、视野,创造美好现在和将来;是否关心客户企业的变革和发展,适应甚至引导客户的业务和管理演进。比如用户会因为使用你的产品,感觉工作从无序变有序、工作心态更加积极。 企业从产品中感知到趋势和问题,获得面对挑战的能力和工具。

另一个是客户评价。企业对产品的评价和决策,是由个人评价和集体评价形成的,涉及企业内多层次多角色的综合评估过程。从角色看,可以有3个视角:用户个人评价、利益相关人评价、企业决策对产品价值评价。从人评估产品的大脑活动来看,分为3个层次,本能、行为、反思。这里概要地列举一些评价需求,但需要根据具体产品和目标客户,做细化。使用这个模型来拆解客户对产品的评价,结合设计评价的4各层次,在产品里考虑每部分如何实现和满足。

关于体验设计是否重要,有些观点认为在2B领域,价值为王,体验设计差一些不是问题。在企业决策中,体验的影响通常是隐性的。但我认为价值是通过体验来呈现的,在这个体验和习惯被大量训练的时代,你无法忽略用户“感受”对评价反馈的巨大影响。尤其红海产品和早期产品。因此要非常重视。

二、产品的调性和风格

2B产品,也需要根据行业特性、用户特性、产品定位和公司策略,确定产品的调性和风格。你希望用户感知到的系统是一个机器人?工具集合?流程平台? 希望它呈现冷峻准确,还是主动友好?这些决定了体验设计、内容设计、互动设计、视觉设计的风格。 尤其即将到来的AI产品时代,产品具有一定的“人性”,那么你需要它是个什么样的“人”。这部分不多说。

三、企业的产品原则

以下一些原则,其实还是产品层面的原则。但之所以将他们拿出来,放在企业层面说,是因为这些原则都是直接受到公司经营、公司管理层、公司文化影响的。要站在企业层面,确定这样的一些原则。才能让产品团队在具体产品工作中安心做产品,不会因为“非产品”的因素冲击,使得产品工作变形。

  • 好的产品,应嵌入新生产要素,使得用户体验有大幅跃迁甚至颠覆。
  • 要为核心场景的业务目标做设计,为本质需求的解决方案做设计。而不是某个客户提出的需求、甚至某个客户想要的解决方案。
  • 不要尝试在产品中帮客户解决所有问题。确定好横向的边界和纵向的边界。横向是覆盖哪些业务环节和操作环节。纵向是环节里帮客户做到什么程度。 把覆盖的环节,做到极致。把选择器和一些权责,交给用户。
  • 要以产品思维做产品。要整合资源,为目标问题域和目标用户提供独特价值。定位用户和问题、分析问题、设计和实现解决方案、实现解决方案,对客户交付解决方案价值这样一个系统化过程,要通过建立多层模型,落实这个过程。 既不是累积“客户需求”、也不是自我陶醉的“领先技术和方案预设的方案”。要建立用户心智模型。要求所有用户按照设计者的“逻辑”来使用产品,是没有建立用户心智模型。是面向设计的产品,不是面向用户的产品。
  • 产品是一个理性的迭代试错过程。要在迭代和用户的逐步验证中,验证价值点,快速完善产品。不要期望一次就完美,那会产生很多无用设计、来回修改、增加产品复杂性、减缓产品上市速度等。这也是精益创业的核心,即分析信息、提出假设、快速验证、将成功规模化推广。哈佛商学院Stefan H. Thomke教授在哈佛商业评论上有一篇文章:Act Like a Scientist: Great Leaders Challenge Assumptions, Run Experiments, and Follow the Evidence,也是个非常好的参考理念。
  • 俞军的产品价值公式:用户价值=新体验-旧体验-替换成本。 不要作替换成本太高、或新体验价值提升不大的“新产品”。
  • 要做高级的产品,而不是低级的。低级意味着:多欲的、简单的、盲目的。高级大概是:克制的、极致的、特立独行的,有自我坚持的完整意识的。

四、产品层面的设计原则

企业业务场景要求的设计原则:

  • 可配置性。同一个场景功能,不同客户可能有不同的做法。产品要运行用户通过配置支持自己的习惯和模式。
  • 模块松耦合。2B产品通常功能多,各功能间要无关联或松耦合。
  • 完善的错误处理机制。根据需要实现:规则提醒、第一时间禁止错误、执行前预知结果、可监控执行过程、重大影响的操作可中断执行、已经完成操作可撤销。
  • 闭环。逻辑严谨,流程闭环,信息闭环,交互闭环,异常流程闭环。
  • 默认功能和默认配置都只为“积极的多数场景”。同时,基于用户分层、需求分层、信息分层、场景分支分层、和范围边界,提供各种可能性的解决办法。
  • 提供场景里提高处理效率的工具。

企业用户需要的设计原则:

  • 控制力。用户需要随时掌握任务状态、进展,随时可以控制任务的走停等。
  • 确定性和安全感。用户每时每刻都知道已经发生了什么,现在能做什么,应该怎么做,会有什么结果。 所有操作,都应该“与期望一致地”响应和执行。超出预期的给多给少,对企业用户都是增加心里负担。
  • 产品要让用户完全理解,不要有客户需要猜测的、无法知道的后台逻辑;但如果后台逻辑过于复杂,可以建立用户模型,让用户从用户模型角度获得确定性。windows系统的文件夹是个很好的例子,无需用户理解系统内的复杂的文件存储、索引块等逻辑。
  • 不要让设计师和公司的想法和目的,影响甚至阻碍用户的业务过程。比如不在用户的业务过程中要求输入产品运营所需数据。
  • 使用用户的业务语言,而不是技术语言、系统设计语言。

作为一般性SaaS用户需要的设计原则:

  • 一致性和稳定性,系统要行为一致、稳定可预期。
  • 让设计消失。把业务本身的复杂性之外所有产品设计、使用的复杂性尽量缩减到最小程度。让用户清晰地感受业务、处理业务,而无需花精力应付“产品”“系统”。
  • 诚实。不要用以欺骗用户获得信任。
  • 不要求用户记忆,在系统中呈现状态、提示考虑用户各种异常时,系统如何帮助用户终端后”无记忆“情况下继续。
  • 不要潜规则。不符合用户的常识理解,需要用户根据结果来分析判断后台实现逻辑。更要避免不按某种潜规则操作时,就获得惩罚和混乱。
  • 前提条件最小化。某功能执行时需要的配置,只放最小要求。
  • 不要急于表达自己,先成为用户,感受需要什么。
  • 准确、清晰、简短的文字表达。避免长句难句、模糊的、有分歧的表达。
  • 参考其他被广泛使用的设计原则,如19 Laws of UX、google产品设计原则、尼尔森10大可用性原则。

五、设计工具

有几个2B SaaS产品设计的工具,包括用户研究、场景分析、用户旅程图、心流、设计改进元素矩阵。相关书籍和资料很多,基础方法就不赘述了。 这里只说一些使用感受。

1. 用户研究

与2C领域所说的痛点痒点喜怒哀思求有所不同,2B领域,我们也谈同理心,谈系统的感官和使用感受是否让用户舒适省心、谈用户的角色内任务实现的快速流畅有成就感、谈通过系统他提升了对自己的工作的安全感和掌控度、谈他与周边流程合作者的高效对接、谈他在岗位上的成长。2B的用户,要考虑“人”,更要考虑“角色”。最终考虑”人“更好的完成角色,但不限于角色。

  • 做用户研究,考虑用户的使用场景导致风格和用户使用姿态;
  • 给特定集体做产品,要充分研究集体人格(集体中形成的思考和行为模式)、共同记忆和核心观念。同样的东西,对一些人是简单的,是常识,对另一些任则是复杂的、不好理解、不习惯的。
  • 把客户当作样本。任何客户提出需求,甚至直接提出“解决方案”。都应该小心分析其广泛适用性,剥离其个性化的部分。如果习惯于直接按照客户说的去做,那产品迭代的过程,就变成“拉链工程”

2. 场景分析

场景驱动的设计也有很多资料可以参考。

首先,理解用户体验和操作的层次结构:人-环境-目标-任务-动作-操作,用户是谁,包括其角色特征和非角色特征是什么;用户的生存环境和使用环境如何;用户在产品中完成哪些目标;每个目标是通过完成哪些任务来实现;每个任务要执行哪些动作;每个动作涉及到哪些点击、填写、选择等操作。我们要站在人-环境-目标的层面考虑产品的价值设计,在任务-动作-操作层面完成产品的流程和体验设计。

可以把一个任务做一个业务场景、把一个动作当做二级场景,或者微场景。要考虑4个touch point的设计:

  • 微场景的用户交互体验。每个页面都要考虑用户为什么进来,进来干什么,页面能否满足。
  • 场景的整体体验,包括微场景衔接体验,和场景整体感或者说故事感。任务的多个页面视图之间如何组织让用户清晰,没有疑惑,可掌控全局自己决定怎么做。一个场景里的多个操作,在系统里要有整体感、秩序感,不要让用户感觉凌乱的分布,不知道如何互相影响和协作。2B不需要惊喜和探索,需要掌控。
  • 场景与场景间,基于上下文的衔接体验。
  • 场景中涉及与系统外工具、流程、信息的衔接体验。微场景-,是否只是过渡页面. 不要像游戏那样,走一步才知道下一步。

比如一个数据中心运维系统,考虑运维工程师用户,大概是个技术青年,他需要做很多具体技术工作,确保服务器运行温度并做信息汇报;以确保服务器运行目标而言,需要主被动发现服务器故障、需要快速处理故障等任务;处理故障任务又需要确定故障机器、分析故障原因等。

分析故障原因这个动作,在具体的故障分析界面或日志界面或机器详情界面,需要信息分布合理、可以搜索、这些操作的响应都应该舒适高效。如此逐层分解下去,将场景和用户旅程图结合起来。

3. 用户旅程图

非常典型,资料和经验分享无数,不赘述了。使用中可以结合心流的理念做设计,关心每个动作、页面,用户心理状态、目标诉求、心理感受。

4. 心流

2B产品不需要用户上瘾,但希望用户在产品使用中能保持注意力和保持心流,从产品出来时感受到成就感、控制感。因此,编配客户交互流程时,要建立和谐的业务流、动作流、反馈流。用户要感知到自己在用一定的力,一用力就有反馈有进展,通过这种小成就感和流畅感一步步完成了任务。可以参考《About Face》里关于流的部分,以及《心流》这本书。设计团队可以建立一些如何帮助用户建立心流的细粒度的设计原则,这里列举一些例子供参考。

  • 页面结构清晰。页面可以分为视觉结构和业务功能两个层次,让不了解业务的人快速浏览页面,说出页面可能提供的功能,是检验视觉结构的一个办法。 让没用过系统的从业人员设计师可以尝试让旁人快速理解页面结构,来检验设计是否合理。
  • 高频操作的点击区最好是区域热点
  • 400ms内反馈
  • 优化响应但容许延迟(即时反馈,如果不能应运行中断后返回查看进展和结果)
  • 让必要的工具近在咫尺
  • 提供无模态反馈。即反馈不打断正常操作流,如word下边的字数、鼠标位置等
  • 用动画动作过渡增强和保持心流
  • 给用户默认配置,避免空白状态
  • 不要让用户迷路,反映当前所在位置,以及退后方式
  • 避免不必要的报告
  • 减轻心流负重:提供选择而不是提出问题;隐藏弹射座椅的操作杆(让高效的操作过程,不感知风险操作)、区别命令和设置(大部分时候命令直接完成,需要设置只是少数,如直接打印和打印配置界面的区别,不要让一堆参数打断心流);避免不确定性的提示
  • 控制任务实现距离: 有人说2B可以不追求少点击一次鼠标。 我不尽认同。不盲目追求减少点击次数,但每次点击都必然需要一些思考、是一次任务的动作链条。如果设计产品时不考虑这个,可能放任工作链条的增长。用户完成一次任务的非业务精力就会耗的多,潜意识就是系统操作很多,有复杂性。 这各种感觉无论对于早期赢得客户,还是我们强调关怀性,尽量提升客户使用过程中的轻松感,都是不利的。 因此要注意点击的次数,和每次点击的有意义性。使客户在几个非常明确的点击后就完成了任务。不要把客户的心流耗散在点击的迷宫里。

5. 设计改进元素矩阵

  1. 列出需要呈现的元素
  2. 元素间多种可能组合,形成若干可能的组件
  3. 正相交的组件,多种组合成多个方案
  4. 根据判断标准,选择合适的方案

6. 其他可以参考使用的设计工具

  • KANO需求分类模型
  • 40个发明原理
  • SCAMPER产品改进方法
  • 病毒式营销传播的感染力6原则,社交货币、促因、情感倾向、公众、使用价值、故事
  • Fogg行为模型

本文由 @养条虎头金 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!