功能列表
1.功能列表
本演示项目为单校版本,专门为一个学校的在线职业技能培训提供服务。通过对原始需求分析、目标用户分析、干系人分析、竞品分析和情景分析后得到的功能和功能启发进行整合,获得如下功能列表(由于本节是以上各环节的成果汇总,列举得详细一些):
模块 | 一级功能 | 二级功能 | 三级功能 | 重要度 | 规则说明 |
---|---|---|---|---|---|
角色权限 | 节点管理 | 节点增删改查 | A | 基于RBAC的权限管理,实现按钮级权限控制,包含数据、操作、按钮、目录4大类权限。 | |
角色管理 | 角色增删改查 | A | 内置班主任/老师/学员3个系统角色,可自定义新角色。 | ||
角色权限配置 | A | 为不同角色设置对应的权限节点列表。 | |||
角色用户授权 | A | 为用户分配角色,使用户获得对应的权限;一个用户可以获得多重角色。 | |||
菜单管理 | 系统菜单 | A | 将菜单与权限分离,使得菜单管理更加灵活。 | ||
角色菜单 | A | 为不同角色设置不同的菜单(来自于系统菜单),每增加一个角色需要设置一次菜单。 | |||
系统设置 | 略 | A | 基本的网站信息配置、全局配置以及一个动态json配置库。 | ||
内容管理 | 略 | A | 基本的文章分类、发布文章的功能。 | ||
消息管理 | 略 | A | 基本的消息推送配置功能。 | ||
页面管理 | 略 | A | 基本的营销页面搭建系统,依赖可视化页面(组件化)搭建技术,适用于活动页、介绍页的搭建,每个公司内部各不相同,如果公司没有的话可以参考百度AIpage、竹子建站之类。 | ||
学校管理 | 略 | A | 学校基本信息、关于学校页等基本管理功能。 | ||
考试库 | 试题 | 分类管理 | A | 分类包含:分类名/共享属性/归属人。试题一般属于某一个老师,可将分类设置“共享”属性,以便成为公共分类,被其他老师使用。 | |
试题创建 | A | 支持:单选、多选、填空、判断、简答、程序。
防作弊机制:选择和判断题信息结构要支持随机展示。 程序题:支持依赖加载、保存运行内容和结果。 |
|||
导入导出 | A | 通过word模板文档导入试题,或将试题导出word文档。 | |||
管理 | A | 删除、上架、下架等,且管理操作不影响已被引用的试题。 | |||
试题选择组件 | A | 能按分类、关键词筛选和选择试题,返回所选试题列表。 | |||
预览 | B | 单独预览试题,直观展示试题最终样式和做题交互。 | |||
试卷 | 分类管理 | A | 类包含:分类名/共享属性/归属人。试卷一般属于某一个老师的素材,可将分类设置“共享”属性,以便成为公共分类,被其他老师使用。 | ||
手工组卷 | A | 创建试卷并手工选择试题,支持:章节排版、试题顺序调整等。(试卷是素材,被复用,不直接用来考试) | |||
智能组卷 | B | 设置试题抽取的分类、个数、难度、分数,自动选择试题进行组卷。 | |||
导入导出 | A | 从word导入试卷(题目自动生成对应试题),或者将试卷导出为word。 | |||
管理 | A | 删除、上架、下架,均不能影响已被引用的试卷。 | |||
试卷选择组件 | A | 能按分类、关键词筛选和选择试卷,返回所选试卷列表; | |||
预览 | B | 单独预览模式,以真实排版查看试卷包含的题目。 | |||
考卷 | 手工创建 | A | 创建并选择一张试卷来生成考卷,设置考试规则,一般考试规则包含:
开放试卷:该考卷在什么试卷可以访问; 考试时长:该考卷建议在什么时间内完成; 考试频次:该考卷是单次考察还是不限次数考察,不限次数时需约束2次之间的时间间隔; 考试模式:练习模式还是考试模式,练习模式可以看解析且不真实提交数据。 |
||
创建组件 | B | 供对外使用的组件,可选择一张试卷,组件自动创建考卷并返回考卷码,供业务端做后续处理。 | |||
答卷创建 | A | 用户访问考卷,会自动生成答卷,记录该用户的做题记录。 | |||
答题模式 | A | 用户可以在答卷上作答,并提交答题记录。 | |||
评卷模式 | A | 老师可以在答卷上进行手工评卷,或系统自动评卷,并查看评卷记录。 | |||
记录模式 | A | 用户可以查看答卷的评卷结果和解析。 | |||
练习模式 | A | 用户在练习卷上进行反复练习。 | |||
考卷统计 | A | 按考卷维度,对其关联的。 | |||
管理 | A | 删除、启用、停用,删除后不删除答卷数据。 | |||
错题本 | A | 用户查看自己每张答卷出现的错题。 | |||
考试记录 | A | 用户查看自己的答卷记录。 | |||
答题记录 | 创建 | C | 考卷是严格的体系考试,单独保存和统计;
但是在教学中可能会随机发题(临场发挥),这个时候可以专门用答题记录管理。 创建时,主要关联创建的场景和所用的题目。 |
||
记录 | C | 记录:场景-用户-题目-作答记录的记录。 | |||
互动课程 | 房间 | 创建房间 | A | 房间是互动课程的基本组织形式,一个房间有开放时间、参与人数、角色等信息。并且互动课堂是底层功能,创建房间一般用于某一课时的直播。
互动白板一般是基于WEB RTC和canvas技术开发,市面有多家SDK厂商提供,可以快速用于互动课堂的支持。但是,它不能成为核心功能,一是没有特别的技术壁垒,二是没有较高效地解决某个教学需求,三是主要是还是很难达到远程软件操作的流畅度要求。但是对于讲课、PPT笔记、多人白板互动,一般足以支持。 |
|
互动教学 | 讲师模式 | A | 仅允许老师讲课,学员不可使用白板。 | ||
互动模式 | A | 支持老师和学员在共同白板上互动,也支持每个学员在各自白板上互动。 | |||
上台模式 | A | 老师可以选择某一个白板进行展示和讲解。 | |||
画笔 | A | 基本的轨迹画笔:粗细、颜色、笔触、笔刷调整,
轨迹智能调整:轨迹接近基本形状时,自动调整为适当的基本形状。 |
|||
基本形状 | A | 支持拖放基本形状,如矩形/圆形/椭圆/三角形/多边形等等,并进行一定的调整。 | |||
PPT画板 | A | 导入PPT自动转为H5,并可进行翻页和支持画笔。 | |||
视频画板 | B | 导入小视频并进行自动控制播放。 | |||
便签 | B | 虚拟便利贴。 | |||
脑图 | B | 在白板中创建和编辑脑图,脑图是一种教学中常用的讲解分类、推导的图表。 | |||
教学仪器 | C | 互动白板中不断拓展教学仪器,是的互动教师有更加广阔的拓展空间。
职业技能的教学仪器:流程图、甘特图、文档模板等。 学历教育的教学仪器:三角板、圆规、仿真实验室等。 |
|||
互动管理 | 自动截图 | B | 互动教学过程中,按照一定规则自动生成截图。 | ||
回放视频 | B | 支持整套课程的回放视频自动生成,能够指定生成方式:白板视频、PPT画板视频、多路布局视频等。 | |||
资源统计 | A | 能有效记录课堂的最高人数、平均人数、占用存储量、所用流量等,以便实现成本较为精细的核算。 | |||
课程库 | 普通课程 | 创建课程 | A | 课程库是底层基础资源库,普通课程用于按课程对外进行售卖,如果普通课程被引用到班级则自动生成班级课程(部分字段改变),班级课程不单独售卖而是在班级中打包售卖。因此:
普通课程:可手工创建、用于单独售卖; 班级课程:不可手工创建自动生成,不能单独售卖,大部分信息不可编辑。 普通课程在创建时,需指定是否允许被班级引用,允许的话,则班主任排班时可以引用课程,调整课时时间、为课程老师生成日程和提醒。(因此,课程老师不能随意调整班级课程)。 创建课程:仅需要填写课程名称、类型(直播、录播)。 |
|
完善基本信息 | A | 包括:副标题、分类、价格、优惠政策、用户群差异化定价、连载状态、可被班级引用、学习模式、学习有效期、标签和状态等基本的介绍信息和营销信息。 | |||
完善课时安排 | 课时信息 | A | 包括:课时名称、课时老师、课时教学预计时间,其中录播课没有课时时间。 | ||
教学任务 | A | 为本课时添加教学资源,支持多种教学资源。
资源类型:图文、PPT、PDF、三方直播、直播间、普通视频、普通音频、附件。(录播课不支持设置直播间和三方直播) 资源内容:不同类型有不同的内容添加交互。 完成条件:可以为不同资源设置完成条件,有默认值,标记用户是否完成该资源的学习,用来生成学习进度。 |
|||
课程测评 | B | 为课时添加课后的练习卷或考试卷,并设置阅卷老师。 | |||
课程老师 | A | 教学老师读取课时老师并去重;
可设置一名助教。 |
|||
课程测评 | A | 为课程设置测评的练习卷或考试卷,用于课程的结业测试,并设置阅卷老师。 | |||
订单管理 | B | 普通课程可以售卖,因此有课程下单的记录和统计。 | |||
学员管理 | A | 指该课程的报名学员(而非学校的学员)。一般有几种学员来源并对应相应的操作:
购买学员:通过购买而来的学员。 导入学员:直接在学员管理导入学员名单的学员。 对学员提供“发起签约”“开除”功能,可以与学员进行电子合约签约、也可以开除范围教学规定的学员。 |
|||
进度管理 | A | 通过统计查看各学员的学习进度情况,并可通知学员进度注意事项。 | |||
签到管理 | B | 直播课可开启签到,用户在规定时间进行手工签到;
录播课不可开启签到。 |
|||
笔记管理 | B | 学员学习时,可以在课程、课时中进行笔记记录,能查看各课时或课程的笔记记录。 | |||
问答管理 | B | 学员学习时,可以发起问答,其它学员或老师可以回复,并查看历史的问答和回复。 | |||
评价管理 | B | 学员可以对课程进行评价,并查看学员的评价。 | |||
班级课程 | — | — | A | 班级课程不能手工创建,只能系统自动生成,创建人为被引用原课程的创建人,且课程信息不可修改。部分可修改信息,只能由引用课程的班级班主任修改。
该场景非常重要,课程提供给班级使用时,课程的安排由班主任来组织和协调,课程老师不能随意修改已引用课程的内容和排课,避免班级组织更难。 |
|
课程分类 | A | 包含课程分类名、共享属性。
设置了共享的分类,该分类的课程可以在全校被其它老师查看和复制。 |
|||
课程日程 | 日程表 | A | 由于课程会被班级引用(课程老师不能及时知道),因此需要自动生成课程日程表,并提醒老师自己的课程的教学安排。 | ||
日程设置 | B | 每个老师可利用的时间不同,老师可以自行设置不可排课的时间,用于班级引用课程或自己课程课时安排时,进行校验。 | |||
教学管理 | 专业管理 | 专业增删改查 | A | 是教学组织的一级分类,一个学校可以开设多个专业。 | |
专业详情编辑 | A | 专业介绍通过页面编辑页实现更加现代化的内容呈现。 | |||
班级管理 | 班级创建 | A | 班级是教学组织的基本单位,尤其是技能培训直播课的组织。比如平面设计专业,可以分批次开设多个班级进行教学组织。
创建班级时,填写班级的基础信息,包含: 所属专业、班级名称、班级报名起止时间、学习起止时间、学费原价(由课程累加)、班级学员上限等。 |
||
手动课程排课 | A | 选择1门到多门课程,作为本班级的课程安排。对于直播课程。原课程的时间安排并不一定适合班级的时间安排,因此,选择课程后需要继续调整课时等信息的修改。
课时时间:班主任可以修改班级课程的课时时间,但是不能与课程老师的日程设置冲突; 课程测评:可以删除课程原课程测评或修改阅卷老师; 课时测评:可以删除课程原课时测评或修改阅卷老师。 |
|||
智能课程排课 | B | 协调课程和老师资源是非常繁琐的事情,能够根据课程分类、老师日常安排,自动选择课程和课时时间设置,然后进行手工微调。 | |||
老师信息 | A | 课程老师:由所选课程进行自动读取;
助教老师:由所选课程进行自动读取; 班主任:可以设置一名班主任,管理班级。 |
|||
结业信息 | A | 为班级设置结业的练习卷或考试卷。 | |||
订单管理 | B | 如果是收费课程,需经过订单库流程,学员在订单支付后进入班级报名。 | |||
报名管理 | 报名记录 | A | 学员填写报名表(可配置报名字段),并经过审核后,进行电子签约(可关闭)后,成为班级正式学员。
报名表:用于了解学员的期望和基础; 签约:用于免责或其它教学管理目的。 |
||
报名表设置 | B | 设置是否启用报名表,并配置报名表。由于我司有自己的表单系统(类似金数据),能够调用组件创建表单、关联表单、获取表单数据、获取表单统计数据等。
如果没有,可以独立建立一套简易表达系统,被报名表调用复用。 |
|||
签约设置 | B | 设置是否启用电子签约,由于我司有专门的电子合同系统,所以可以直接使用其服务接口创建合同、乙方自动签署、甲方短信通知、甲方签署、电子存证等一系列功能;
如果没有可以选择一个第三方电子合同系统。 |
|||
学员管理 | A | 学员来自于2类:
一是通过报名而来;二是通过导入学员而来。 因此需要:导入学员、开除学员等功能。 |
|||
签到管理 | 签到记录 | A | 读取各个课时的签到记录。即签到是根据班级课程各课时的签到记录生成的,如果课程为录播课是没有签到记录的。 | ||
实时签到 | B | 自动读取当前所处的课时,并实时提醒当前未签到的学员,可以很好的提升点名体验 | |||
到课率 | B | 自动统计每一节课的上课签到、下课签到和满课签到,做好签到趋势分析,有助于班主任进行教学管理 | |||
请假 | B | 学员若无法参与上课,可以进行请假;班主任统一后,请假记录生效,并作为请假率统计 | |||
进度管理 | A | 读取各个课时的学习进度+班级结业进度构成。 | |||
学习笔记 | A | 包含班级的笔记、课程笔记和课时笔记。 | |||
学习问答 | A | 包含班级的问答、课程问答和课时问答。 | |||
专业页 | A | 展示专业介绍和可报名的班级。 | |||
班级页 | 未报名模式 | A | 查看班级基本信息、课时安排,并进行报名。 | ||
已报名莫斯 | A | 查看班级基本信息、课时安排、参与班级互动等。 | |||
普通课程页 | 未购买模式 | A | 查看课程介绍,并进行购买。 | ||
已购买模式 | 学习页 | A | 查看课程内容,并进入课时学习页,直播课可进入直播房间学习。 | ||
班级课程页 | 未报名模式 | A | 查看客车介绍和课时安排。 | ||
已报名状态 | 学习页 | A | 进入课时学习页进行学习,直播课可进入直播房间学习。 | ||
学员中心 | 报名管理 | A | 已报名班级的管理和入口。 | ||
课程管理 | A | 已购买的普通课程的管理和入口。 | |||
订单管理 | A | 课程或班级的购买订单记录。 |
2.方法学习
2.1 什么是功能列表
功能列表就是为了满足需求而设计的功能点集合。
功能的来源不是凭空产生的,在我们这个系列中,前面的每一个分析环节都是在获得功能启发,为梳理功能列表提供功能点基础。所以,这里的功能列表,并不是一般意义的编写一个功能表格,而是作为产品设计基础能力,是一套有效梳理功能点的方法。
2.2 梳理功能列表的意义
梳理功能列表,是为了将原始需求、目标用户分析、干系人分析、竞品分析、情景分析得到的所有功能点以及产品经理对产品本身的功能思考进行整合,得到一个全面的备选解决方案列表。它是制作产品原型的前提,为产品原型提供指导,但是,他并不就是我们产品的功能(或者说全部功能),也不是最终解决方案。
2.3 梳理功能列表的步骤
要将之前获得到的功能及功能启发有效的整合起来,可以才有以下几个较为固定的步骤:
- 功能整合:把全部功能归纳、整合成为一个功能结构图;
- 筛选功能列表:明确功能的价值,筛选出必要的功能列表;
- 重要度排序:根据功能价值的大小,标记出功能的重要程度;
- 功能规则描述:为每一个功能添加必要的功能规则描述,为产品原型设计提供有效指导。
以上也是一个功能列表需要包含的主要信息字段,所以,一般功能列表的表头如下:
模块 | 一级功能 | 二级功能 | 三级功能 | 重要度 | 规则说明 |
---|---|---|---|---|---|
2.3.1 功能整合
我们在前期分析中得到了几个功能启发的列表,把它们简单的复制到一个表格,显得杂乱没有逻辑,我们如何将功能进行结构化的表达,不妨试一试以下几个策略和步骤。
2.3.1.1 关注需求的直观解决方案而不是实现细节
这是一个约束原则,我们在做功能梳理而不是功能设计,因此不应该一开始陷入“这个需求的前端和后台是什么”的细节,关注到满足用户的需求我们的提供的功能方案是什么(一般来说,就是更关注前台功能)。当具体实现时,才去考虑需求实现的完整业务逻辑及相应后台功能。
2.3.1.2 从角色出发
一切功能的核心都是为用户服务的,根据用户的不同需求划分好一系列系统角色,然后结合“角色的需求+功能点”进行整理和归类,是一种高效的、清晰的方式,这是我的经验。比如针对职校系统而言,核心的角色应该有管理员、监督者、校长、班主任、课程老师、助教、学员和游客。这些角色是某一类用户或某几类用户的集合,每一个角色都有自己的需求,与原先的功能列表结合,就可以找出某一个角色所需要的功能了。
2.3.1.3 分类与归纳
功能整合时,一般需要把原来涉及细节的5-7级的功能点,建议整合为不超过3级的功能结构,我们可以借助“分类”和“归纳”2种方法。
分类:类型相同的功能化为一组。比如,在干系人和情景分析中,都有教学提醒的功能。
归纳:是分类的后一个阶段,书面解释是“归拢并使有条理”。把一系列功能概括出一个集合(如完成某一个任务、某一个抽象逻辑),归纳结果一般为一个功能模块和一个大功能,如:报名、签合同。
2.3.1.4 功能结构图
功能结构图,是一种用于描述产品各个功能的从属关系和逻辑结构的、脱离于具体字段信息的思维工具。将分类和归纳的功能,使用功能结构图进行组织,形成功能“鸟瞰图”,不仅让功能更加清晰、逻辑更加直观,更重要的是通过功能全貌清晰地看到产品功能点及从属关系,避免梳理过程中的功能缺失,并在不断check过程中不断补充和完善功能。所以,我们在功能整理时,常常使用它来进行分类和归纳,并检查整理的结果,它很简单且高效。
比如,本次在线职业教育“教学模块”归纳的功能结构图如下:
2.3.2 筛选功能列表
为了更好进行下一步分析,往往我们需要把功能结构图改为列表。得到一张经过整合的完整功能列表后,还需要对功能进行打标和筛选,并不断优化列表(功能继续归纳重组)结构,为后续产品设计提供更明确的方向性指导。
2.3.2.1 找核心功能
好的产品应该有自己的核心功能,其满足了核心用户的核心需求,并有独特的竞争力和商业价值。在对核心功能思考时,需要建立自己的核心优势,否则核心功能不够“核心”,就很难在市场竞争中得到核心用户的认可。核心功能一般来自对目标用户的分析产生的功能,或是在重要用户情景中用户痛点问题产生的功能启发,也或者是对竞品功能的体验或技术的改进。
把焦点放在“要解决什么需求+如何解决需求”上进行思考,是找到核心功能最有效的方式。比如前端程序教学,学员一般在学习时“需要手写代码来加深理解”,一般的解决需求方式有很多种,比如传统的做法是“看视频,然后暂停播放,自己去练习”,但是scrimba创造了“边看教学并直接在教学中输入代码练习”的方式,以更好的方式解决用户需求并有一定技术壁垒,这就是核心功能。再比如,对于K12的在线教育也一样,传统的视频直播,老师很难掌握学生的学习情况,因此“直播+互动白板”,使得远程教学体验媲美线下面对面教学。再比如,考试系统的设计,像支持的题型、智能组卷、防作弊虽然是重要功能,但竞品基本也实现了,老师在出卷时最核心的需求是“要快要便捷”,自己编辑题目是非常繁琐且烦躁的事情,如果有丰富的试题库,就可以极大地解决老师的难题,因此“激励老师共建题目库(获利)并形成海量学科题库”就是考试系统的核心功能。至于如何实现核心功能,在具体原型设计和需求文档撰写时再深入考虑。
当然,在思考核心功能时,还需要结合:细分市场、自身资源优势、自身技术优势等因素进行考虑,每个公司有所不同,因此需结合自身的情况综合考虑。
2.3.2.2 筛选其它功能
在筛选其它功能时,常常采用“三问法”帮助我们思考,就是要对每一个功能多问问以下问题:
(1)为什么要做
互联网产品要添加新功能非常容易,不可避免地增加很多“用户可能会用”的功能,功能越来越多给用户带来的干扰也就越多(反而核心价值被忽略),也一定程度上影响用户体验。因此,思考清楚为什么要做这个功能:是符合公司的某一项商业价值?是满足用户的某一项需求?是普遍用户存在的一个痛点?
(2)为什么这么做
知道要做的事情,接下来就是把事情做正确。为什么这么做,需要权衡“需求满足程度、体验、成本、资源”等多方面因素,需要不断进行反思和反问,有可能进一步修正和优化已有功能方案。
(3)还能怎么做
满足需求的方式是多样的,想到尽可能多的解决方案,才能更有效地找出经过思考后的最优解。并且,最优方案往往不是一层不变,随着公司发展、内外部环境的变化,解决方案也会不断发生变化。
我们在梳理功能时,不断运用“三问法”进行思考,可以找到更多的备选功能,甚至可以找到当前最有的功能。这一思考方式,在面对同一需求有多个不同解决方案的功能时,可以帮助我们筛选出尽可能正确的、合理的功能。
2.3.3 重要度排序
这里的排序并不是开发的优先级的排序,而是从满足需求的角度来说,其商业价值大小的排序,更多的是分析和标记该功能的重要程度。一般可以划分以下几种重要度:
2.3.3.1 “A”必须要有
指在产品设计中必须保留和实现的功能。以下情况都属于必须有的功能:
(1)核心功能
在上述已经分析了如何寻找核心功能,毫无疑问核心功能是必需要有的功能,是产品落地后核心竞争力所在。比如,为职业技能提升提供在线直播学习的功能,其核心一定是互动性和引导性(而非被动的接受视频),其核心在于“远程互动教学和学习”,在互动的实现上可以是随时与讲师交流、在画板上共同创作、随时演练等等。当然,“职业技能”还是一个很宽泛的词语,包含着太多可能的解决方案,所以如果能进一步聚焦某一项技能,其核心功能可能更加具体、更加核心。
(2)基本功能
虽然不是核心功能,但产品本身也不可或缺的基础功能,来自目标用户和干系人的刚性需求。这些功能一旦没有,用户可能就感到十分痛苦设置无法满足基本需求。比如,在线技能学习后没有视频回放、直播安排没有课表及提醒、直播学员没有课程班级组织等。
(3)支撑功能
产品核心功能和基础功能实现需要依赖的功能。比如学员报名、审核、签合同、考勤等等。当然,上述功能尤其是基本和支撑功能没有严格的区分,只是辨别功能的一种分析方式,往往它们也没有明显的边界,但是它们都是一个产品不可获取、必须具备的功能。
2.3.3.2 “B”建议要有
指核心需求之外,但又能普通提升用户满意度的功能,所以一般是围绕用户体验不断改进的非核心功能或普通用户期望的功能。这类功能往往会受到成本、实现难度等限制,但是一旦实现对用户体验有极大提升,所以需要标记出来,平衡多方资源予以实现,或者等待技术成熟时加以改进。比如,在教学过程中,为了提升互动体验和检测学习效果,可以在直播过程中进行发题并回收。
2.3.3.3 “C”可以有
指锦上添花的低频功能或小众功能,这些功能一般来自细分小众人群或特殊的使用情景。比如职业技能教育时,能直接引用老师的素材程序编写和执行查看结果的功能,这往往是针对前端编程学习的需要。低频小众功能不一定总是C类功能,在细分领域,它可能会成为一个核心功能,比如刚刚提到的“暂停播放直接编程”的学习方式,就是scrimba的核心功能。
2.3.3.4 “D”不需要有
指根据我们产品原始需求和用户的分析,不符合设计目的的功能(一般呈现时,这类功能可以不再体现到功能列表中了)。它不一定是功能不好、理念不正确,只是不符合设计目的。比如,针对职业技能的培训,课程教学环节的安排中,不需要“预习”功能;而K12往往预习是传统教学模式中一个非常重要的环节。
2.3.4 功能规则描述
仅仅罗列一系列功能名,往往很难清晰地知道背后的含义/用途或逻辑,尤其是过一段时间后,可能自己都忘记了功能原本的来源和目的。因此,为功能添加必要的功能规则描述,对产品功能进行适当的补充说明就非常有必要。以下内容都可以作为功能规则的描述:
细化功能解释。较为详细地表述功能的目的、用途或作用,或者较为详细地描述下级资源。比如“添加教学资源”,需要注明:教学资源是支持教学开展的素材,支持图文、PPT、PDF、Word、视频、音频等。
描述功能流程。较为详细地描述功能的条件和规则等,比如功能触发条件、运行机制、实现效果、反馈等进行明确说明,为原型设计提供有价值的指导和参考。比如“添加教学资源”,出来资源类型外,其功能规则主要是:每一个教学环节可以设置一个教学资源,弹窗选择资源类型、设置资源标题、添加资源、设置资源完成条件、发布资源后,教学资源即可添加成功。
补充功能逻辑。功能点往往很难体现功能背后的逻辑,需要进行补充说明。比如同样是“添加教学资源”,直播类型课程可以添加6种资源、录播类型课程可以添加3种资源等等。
提取功能亮点。从布局、实现原理、设计、交互甚至提示语等细节处,把功能参考时发现的亮点进行记录,可以作为未来产品原型时的参考。比如“添加教学资源”,用tab抽象出各类资源添加的3个步骤:选类型、设置内容、设置完成条件。
完善的功能规则描述,使得功能列表更加易于理解,使得原始功能分析的精髓被保留下来。完成功能列表的制作,一个产品的基础分析工作就算告一段落,通过一系列的分析,我们实际得到了一张结构化的功能点,但是请注意,这是一张用来参考的、完整的备选解决方案列表,但并不是我们产品最终的功能!
以上从原始需求分析、目标用户分析、干系人分析、竞品分析、情景分析到最后的功能列表制作,我觉得这是一种有效的、易于掌握并有助于提高产品设计能力的基本方法论。该方法论是网龙公司内部根据多年的软件设计经验总结的基础产品方法论,对我自身的工作有非常大的帮助,故结合自己的理解,分享出来。