文章分规划篇和设计篇两篇,分别适合不同阶段的产品经理,大家各取所需,希望有所受益。
之前有写过一个教程《五分钟教你快速上手Axure交互设计》,令我感到欣慰的是那段时间里陆续不断地有读者加我微信向我表示感谢,有创业的,有工作的,也有经营电商的。其实真正要感谢的是你们,正是你们让我尝到了分享带来的喜悦。因为写这篇文章时自己还在校外实习,所以作为小白的我和你们一样也在一点一点地学习别人授予我们的宝贵经验。
机灵出了一个idea或是接到上面的需求,你该如何踏下产品之旅的第一步?先来一次市调?先给产品一个定位?冷静下来吧少年,让我们端杯咖啡看看地图先。
规划篇
战略规划
常见的战略阶段分为起步阶段 、发展阶段和迭代阶段。
根据产品生命周期制定相应的运营策划。
战略受宏观环境与公司内部的双重影响。
产品定位
“在什么样的场景下,用什么产品形态,满足什么用户的什么需求”
一般选择产品定位有三个方向:
- 选择一些未被使用的痛点作为产品定位。
- 选择更高层次(细分)的核心需求作为产品定位。
- 选择垂直角度切入,满足一部分人的需求。
同时最好注意以下几点:
通过产品定位,可以明确功能需求的界线,在产品规划中并不是所有“相关的需求”都要实现,我们要充分考虑需求是否符合产品定位。
商业模式
商业模式的表现形式多种多样,这里向大家推荐“商业模式画布”,如下图:
我们为什么需要有这样只占一页的商业模式图?
竞品分析
首先了解竞品分析的目的:
其次注意分析关键点:
宁可无结论,也不能蒙一个错误结论。
需求决策
总的来说,需求决策可以分为4个阶段,分别是:“搜集需求”、“分析需求”、“筛选需求”、“处理需求”。
需求分析过程主要做三件事:分类、分位、分级。
设计理念
产品的设计以用户体验为原则,对产品功能和体验进行研究并开展设计。这里分为四个等级,形成一个金字塔式的设计理念。
设计篇
设计流程遵循以下目录顺序
信息结构图
罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂。 信息结构图是一种接近数据库结构的图表,但是他并不是真正意义的数据库结构。
上图是一张以众创平台为例的信息结构图,提供给产品经理自己梳理信息内容的同时,也方便产品经理和服务端技术人员沟通数据结构,技术人员会根据这张图表的内容再结合产品原型或需求文档,然后规划和设计出真正意义上的数据库结构。
产品结构图
产品结构图是一种将产品原型以结构化的方式展现的图表,结构内容也如同产品原型一样,从频道到页面,再细化页面功能模块和元素。所以产品结构图是产品经理在设计原型之前的一种思路梳理的方式,并不是给其他工作人员查看的文档,通过类似鸟瞰式的结构图可以让产品经理对产品结构一目了然,也方便思考。
上图是一张以众创平台为例的产品结构图,是将产品原型具体化的一种方式,只是罗列了产品的频道页面和功能,但是没有详细的进行推演,关于细化方面是否符合产品逻辑,是否符合用户体验,这些都是没有深思过的,因此我们接下来就要进行原型设计,开始具体的考虑可行性。
产品原型图
原型设计是将结构化的需求进行框架化,因此原型也被称为线框图,具体的表现手法有很多种,相关的辅助软件也有很多,例如:Axure RP、Balsamiq Mockups、UIDesigner等等。原型也有低保真原型与高保真原型之分,相较低保真原型而言,高保真原型从视觉与交互上更为接近产品的真实效果,但是制作所需的时间成本高。
原型设计的表现手法主要有三种:手绘原型、灰模原型、交互原型。
以上三种方法并不是渐进的流程,而是三种原型设计的方法,具体取决于你的产品需求和团队要求。
产品用例图
用例(Use Case)是一种描述产品需求的方法,使用用例的方法来描述产品需求的过程就是用例模型,用例模型是由用例图和每一个用例的详细描述文档所组成的。
在互联 产品和设计中,用例的使用越来越少,通常有了产品原型再加上功能流程图和功能说明文档就能够将产品需求详细的表述清楚,所以也没有必须撰写用例了。但是在大公司里,往往会追求产品流程的规范性,要求撰写用例,不过在敏捷开发的时候也会采用其它更有效率的方式,不一定非要撰写用例。
功能流程图
由于用例文档以文字为主,并且格式复杂,不适用于高效率的产品需求表述,所以展现逻辑流程的“功能流程图”是一个简洁直观的可替代用例文档的方式。
功能流程图是一种使用图形的方式表示算法逻辑的图表,其展现方式也不会产生“歧义性”,便于理解,逻辑出错时也非常容易发现,并且可以直接转化为程序需求描述文档。
PRD文档
前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节,到了这一步的时候我们已经非常清晰的了解产品需求,此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。
产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。因为每个人的习惯和团队要求都是不一样的,所以产品需求文档没有统一的行业规范标准,无论以什么样的格式撰写产品需求文档,最终的目的都是让执行人员能够理解产品需求,根据需求完成产品。
关于PRD的范例 上有很多,这里就不一一贴出来了。不过个人认为,设计师或开发人员拿着Word版的PRD很难直观地审查页面中的元素属性、交互效果或是用例规则,合理地利用Axure中的属性、说明与样式可以更直观的将需求说明与元件结合在一起,并准确无误地传递参数信息,所以用Axure写PRD也受到了部分产品经理的青睐。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!