【4007】产品原型的整理归档心得(下)

导语

前面介绍过一种基于项目开发进行整理的产品原型归档方法,今天我再说说另外一种将产品原型整理归档的方法。


用Axure举例

建立原型库

如果说上次介绍的方法比较适合用在协同工作上和快速迭代上,这次这个方法就更适合用于个人的归纳总结,像“知识库”一样的存在。

如下图:

此方法建库比较灵活,根目录的结构决定了日后的子目录形式,怎么建立完全按照自己的思路结构决定。

原型库结构

由于此方法比较灵活,不同的思路,出来的效果完全不一样,所以在建立根文件夹的时候,需要考虑清楚自己的阅读习惯。

[infobox title=”规划思路”]此方法的核心在于根据功能体系进行划分,基于不同的功能版块进行填充模块内容,利用不同的维度定位摆放,还是“小箱子”和“大箱子”组合的概念。[/infobox]

[info]按产品建库[/info]

根目录文件夹为一个一个的产品,每个产品文件夹里都有N个功能版块小文件夹。功能版块里有不同日期的页面内容,由于不是基于开发版本,所以使用“时间戳”对同一个功能的迭代修改进行命名区分。

优势

  • 可以清晰看清产品形态
  • 方便进行竞品间的对比
  • 有助于看清产品的发展轨迹

劣势

  • 可能会存在很多重复和类似的功能
  • 容易造成偏科和思维局限

[info]按功能版块建库[/info]

根目录文件夹为一个一个的功能版块,每个功能版块文件夹里都有N个不同类型样式的小文件夹。最终也是用“时间戳”对每个修改版本进行命名区分。

优势

  • 类似记忆宫殿,可以当知识库结构使用
  • 遇到类似功能问题时,可以直接查阅对应版块进行参考
  • 可清晰查阅发展形态

劣势

  • 缺乏产品大局观
  • 不适合工作流,让人无法理解前因后果
  • 时间长后,容易忘记时代背景。(需要用大量备注进行说明)

小结

每个人都有一套自己惯用的思维方式,没有最好的方法,只有最适合自己的方法。就如BAT看似严谨完整的功能上线流程,若放在初创快速迭代的企业,也不一定是好的一个道理。

【4006】“修订记录”与“版本管理”

导语

为什么会将“修订记录”和“版本管理”放在一齐?在我理解中,它们是有密切联系的,每个新版本都有对老版本的一些修订内容,否则也不需要发新版本。

今天说的“版本管理”是指产品岗位上的“版本管理”,并非开发团队内部的“版本管理”,开发团队都有自己的一套版本管理方法和思路,并且因为涉及代码层,所以会更严谨和复杂,在此不做延伸。

修订记录

[infobox title=”修订记录”]一般指文档修正更新后,针对文档进行的修改说明。[/infobox]

修订记录无非就是告诉别人改动了什么,所以最关键的是改动项,它的描述要尽可能使用(主语+谓语+宾语)的表达形式,不要加主观修饰语句。尽量一两句话说清楚事情即可。

改动项包含以下类别:

  • 增加(Add)
  • 修改(Modification
  • 删除(delete)

上图的表格也是仅供参考,需要根据所处团队的实际情况进行针对性设计。有人会问版本号,这里的版本号是该文档的版本号,在文章《关于文件名管理》中也提到过同一个文件,修改多几次,就忘记自己看的是哪一天的版本了,若经历多几个人的协同编辑且胡乱起名后,很难保证文件的信息完整性及准确性。

用“日期”+“版本号”都放入修订记录中,有助于校正文件的最新版本和最新内容。

版本管理

[infobox title=”版本管理”]当一个“产品”存在多个版本时,为了更好的区分哪个是哪个,可用版本号进行识别。[/infobox]

[infobox title=”范例”]v A区 . B区 . C区 . D区[/infobox]

区域解释

  • V:版本(versions);
  • A区:重大变动,里程碑级别的调整;
  • B区:功能性调整,操作流程调整等小型改动;
  • C区:小修小补型迭代更新的调整,一般用于普通版本迭代;
  • D区:极小的细节处理,例如修改文字,上线后发现小bug,临时补发一个版本。

版本号使用阿拉伯数字往上叠加即可,内部人员日常沟通时,说到某个功能,带上“版本号”为背景,大家就能清晰的知道对应的是哪些内容。用户发现问题时,提出“版本号”,也方便开发人员进行问题排查。

小结

巧妙的将“修订记录”与“版本管理”相结合运用,版本说明就是可以轻松的归纳总结了。看上去,这个都是比较繁琐且需要维护的没用边角料,实际上在个人成长管理及项目文件管理上,还是非常好用的,大家也可以尝试开发一套适合自己用的“版本管理”方法,让事情事半功倍。

 

【4005】产品原型的整理归档心得(上)

导语

日常工作中,我们会碰到各种各样的需求,大部分需求都需要使用原型进行表达,不知道大家是否有将制作过的原型进行整理归档,方便日后修改或迭代更新。

原型工具

[dangerbox title=”常见的原型工具”]

[/dangerbox]

原型工具市面上种类繁多,我人比较古典派,还是习惯使用Axure。很久以前,有段时间直接用Execl结合文字和原型直接解决需求,非常方便快捷。但也只是当时快一下而已,随着时间的推移,产品体积的变大,迭代的东西越来越多,Excel的结构不足以轻松的支撑一系列的需求撰写。会出现各种切换不方便,元件调用不方便,导致信息零散,无法系统化的阅读。

每个人的习惯都不一样,使用什么软件不重要,只要顺手就行,下面介绍一下我的一些原型管理的心得!


用Axure举例

建立原型库

[infobox title=”原型库”]原型库就是一个存放产品原型的容器,并不是单个需求的零散原型,而是一个产品整体的原型。[/infobox]

建立原型库之前,首先要考虑目标产品的体积大小。若是体积较大的产品,可以考虑根据不同的终端建立“原型库”。

如下图:

例如一个体积较大的产品,既有PC端,又有客户端包含iOS和Android,还有Portal后台。先要判断iOS和Android的统一性,是否需要拆分,一般来说移动端都是尽量做成一样,一方面减少工作量和另一方面降低用户的适应成本,所以可以一起建库。PC端和Portal端都是单独出来建库。

如果一个产品体积较小,所有终端放在一齐也没关系,只要文件有办法打开,不卡不慢,查找东西方便,就没问题。

原型库结构

首先我们要合理的利用Axure的“文件”和“页面”的层次关系。其实这个和思维导图Xmind等软件有异曲同工之处。其实我曾经使用过两种完全不同思路的结构方式,今天我介绍其中一种思路给大家。

 

[info]这个是根据迭代开发为思路的产品库目录[/info]

[infobox title=”规划思路”]将“文件”规范化,形成一个一个的小箱子,小箱子可以放进大箱子里面,归类存放。有需要时,可以抽出其中一个箱子新建文件单独抽出展示。[/infobox]

[info]定义[/info]

  • 一个需求存在多个文件;
  • 一个文件为一个功能;
  • 一个功能存在多个页面;
  • 一个页面可能存在多个子页面,因为不同的状态下呈现的效果可能存在较大出入。

操作方法

如上文所述,将原型库划分为以下区域:

  • 简介
  • 思维导图
  • 原型图
  • 参考文档
  • 需求卡片

[info]简介[/info]

全部都是描述类的页面,具体页面内容如何规划就不在原型库结构范围,日后再单独抽出来与大家分享。“简介”的目的是为了日后翻看记录的时候有备注,方便联想当时的情况。

[info]思维导图[/info]

一般此区域我只会维护最新版结构,只有关键版本才做老版本的记录,此版块的目的是为了可以清晰有大局观的查看产品形态。但凡和逻辑思路相关的图表都可以往这放,例如流程图,测试用例,提示语目录等。

[info]原型图[/info]

此区域为占地面积最大,需求确定前,在当前版本文件进行设计规划,终稿封存后归入历史版本内,并把对应页面放入所有页面的“产品结构图”。

所有页面此文件除了可以存档外,还可以记录每个版本页面产生的变化,在哪个版本产生了变化等。

[info]参考文档[/info]

就是字面上的意思,构建方法随个人喜好,可以根据需求版本当时的参考分析,可以是自己收录的一些干货,各种用于参考的图像资料。在此,若参考内容很多,建议额外做一个Excel表格作为参考文件的名称及所在电脑文件夹的路径。不需要存放在原型库文件内。

[info]需求卡片[/info]

此区域也很好理解,就是将需求池搬进来,不一定要在原型库中管理。放在此处的原因是,有时候需求评审,涉及跨部门或者有大领导,有这个版块的存在比较完整,不需要在软件间不断切换,影响观看体验,所以,此处可以只放当前版本的相关内容。

小结

以上是我的一些浅见,也肯定有改进的空间,若你有更好的想法,欢迎留言或直接与我交流。

 

【3010】产品经理必修课《用户体验要素》

今天我要介绍一本书,此书非常适合产品新人进行启蒙阅读,书名就是《用户体验要素》。

此书主要是讲遇到问题应该如何思考,如何分析问题。全书最核心的部分就是此图:

大多数人都曾经通过网站购买过一个商品。这种经历几乎每一次都是一样的。

  • 到达网站;
  • 寻找想买的东西;
  • 放入购物车;
  • 提供收货地址;
  • 等待商品送到手上。

这个清晰、有条不紊的体验,实际上是有一系列完整的决策组成。书中将每一层都一一详细的解释及说明,强化对这个思路的理解。

用户体验的整个开发流程,都是为了确保用户在产品上所有的体验不会发生在用户“明确的,有意识的意图”之外。要考虑用户有可能采取的每个行动和每个可能性,去理解用户在操作过程中的各种期望值等等。

下面我简单介绍下书中的几层概念。

表现层

在表现层(surface),你看到的是一系列的网页,用图片和文字组成。一些图片是可以点击的,从而执行某些功能,例如吧用户带到购物车里去的“购物车”图标,一些图片就只是图片而已。

框架层

在表现层之下的是网站的框架层(skeleton),按钮、控件、招聘和文本区域的位置。框架层用于优化设计布局,以达到这些元素的最大效果和效率,使得用户在需要的时候,能记得标识在哪里。

结构层

与框架层相比更抽象的框架层(structure),框架是结构的具体表现方式。框架层确定了再结账页面上交互元素的位置;而结构层则用来设计用户如何到达某个页面,并在他们昨晚事情之后能去什么地方,框架层邓毅了导航条上各个要素的排列方式。允许用户可以浏览不同的商品分类;结构层则确定哪些类别应该出现在相对应最合适的位置。

范围层

结构层决定网站各种特性和功能最合适的组合方式,二这些特性和功能就构成了网站的范围层(scope)。例如,网站提供一个功能,使用户可以保存之前的收货地址,这样他们可以方便再次调用这些地址数据。而这个功能是否应该成为该产品的功能之一,就是属于范围层要解决的问题。

战略层

网站的范围基本上是由网站战略层(strategy)所决定的。这些战略不仅包括了领导者想通过产品获得什么,还包括了用户想通过产品得到什么。简单的说就是一个产品的定位和方向。

小结

将用户体验要素中的各层概念,用于PRD的写作上,还是非常不错的,能轻松的将一个事情描述清楚。

【2004】需求文档需要详细到什么程度?

导语

相信很多产品经理都有这样的一个经历,需求写的太简单吧,开发同学嫌弃没细节。花大力气写个长需求吧,需求评审的时候又发现,大部分人压根没怎么细读过文档。在这里,要抛出个问题

需求文档是干什么用的?

一般来说也就两个用处:1、用来沟通;2、用来存档。

内容够用就好

很多人可能喜欢在这个时候抛出《用户体验要素》中的五个层次(注:用户体验的五个层面分别是:战略层、范围层、结构层、框架层和表现层。),将一个需求拆分成好几个不同的层面进行说明,写完一副这需求写的完美了,人人都能看懂了,什么信息都包含了。对,这确实没错,但这会消耗大量的时间在编辑文档上啊,若非关键大版本的需求,清楚明白就行了,毕竟实际工作场景中,太多的快速迭代版本,什么都一五一十的写出来,在时间分配上也是一门学问。很多时候,画个原型,加一些辅助的说明,远比文字直观。

给谁看

一个需求的立项,也有调研,分析,评审,排期等不同的阶段,不同的需求也有可能会碰上不同的会议,不同的主题,所以这时候给谁看很重要。最关键的是,TA想知道什么。

  • PPT:一般都是包装华丽,文字精简,突出中心,主要靠的是会议的演讲,并不是文件的本身。针对对象:大老板,发工资给你的那个人;
  • word | excel:一般都是条理清晰,层级清晰,列清楚一二三四五。针对对象:开发同学,一般他们喜欢一是一,二是二,不带歧义的描述;
  • xmind | axure:结构化思维,图形化思维,直观容易理解。针对对象:评审会议上的各路人马,大部分人容易理解这是干什么的,方便看图提问,发现问题;
  • 图片 | 交互流程 | 清单:清楚列出该需求涉及页面数量,交互逻辑是怎样的。针对对象:UI和UE设计师同学,解决设计上的布局问题和体验问题。

小结

软件只是工具,模板只是方法,关键在于随心所欲,灵活变通。

【4003】建立属于自己的word文档模板 – 样式篇

导语

一般情况下我们写好的需求文档是给别人看的,但别人收到文档时,此文档对于别人来说是陌生的,单凭“目录页”也很难让别人能轻松浏览。这时候文档的样式结构就很重要了,清晰的样式结构,有助于在文档中寻找所需要的内容,并且方便定位。

核心功能

  • 样式:字体,字号,粗/斜/下划线;
  • 格式:多级列表,段落设置;
  • 视觉需要:产品结构图/导航窗格

样式说明

样式.png

一般打开Word肯定能找到,鼠标“右键”->选择“修改”,如下图:

样式1.1.png

在此处调节自己期望的字体,字号,颜色,粗细等。

样式1.2.png

格式说明

我个人比较喜欢的效果是用:

1. 标题

1.1 标题

1.1.1 标题

这个很简单,找到“多级列表”此功能,并选中编辑格式即可

样式1.png

格式_多级列表.png

最终效果

效果.png

在此处记得一个事情,将“格式”并入“样式”。在样式对应项中,鼠标“右键”->“更新 **以匹配所选内容”

更新前

效果1.png

更新后

效果1.2.png

产品结构图

利用产品结构图进行文档阅读,有助于了解文档结构大纲,并能轻松定位到目标页面。

顶部导航栏选择“视图”-> 勾选“导航窗格”,即可成功打开产品结构图。

文档结构图.png

文档结构图2.png

若需要导出PDF文档,也可以让PDF文档带上这些结构参数,在“另存为”操作时选择PDF格式,并在“选项”中勾选“辅助功能文档结构标识”,PDF即可生成对应文章结构。

PDF文章结构.png

PDF文章结构1.png

小结

软件年年都更新,过几年这操作说明可能不适用,此文虽然介绍的是方法,实际推荐的是方案。天下武功出少林,东西都是可以融会贯通的,此方案对阅读有一定的帮助,所以介绍给大家。