加入收藏 | 设为首页 | 会员中心 | 我要投稿 济南站长网 (https://www.0531zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 交互 > 正文

产品经理究竟该如何进行原型设计(上)

发布时间:2016-11-17 12:34:51 所属栏目:交互 来源:产品壹佰
导读:副标题#e# 经历了漫长的产品设计流程,我们终于来到了最后一个环节,也就是根据之前梳理的产品流程来进行产品的界面设计了。 产品经理其实都知道,在这样一个看重颜值的时代,一个赏心悦目的网站(或者移动APP)是多么重要。每一个产品经理,也都希望自己的

产品经理在将原型图画好之后,往往会特别欣喜,恨不得立马就让全体团队成员看到自己的设计成果。但是,这时候的原型图通常是不完整的,很多场景、因素缺少考虑,小到一个按钮的位置,字段展示、大到功能的流程设计、逻辑设计。如果你就轻易把这么一份不完整的原型交付给技术,不但技术会喷你,搞不好用户也来喷你,甚至Boss也来喷你。所以,打磨好产品原型,尽量考虑各种场景、因素,设计原型时尽量细化分析,让所有人从原型就能看到你的态度,是一件非常重要的事情。

总体来说,原型设计需要表达清楚这么几个地方:

1、界面元素

什么是界面元素,比如文字,下拉框,按钮,图标、图片等等这些都属于界面元素。我们在运用原型设计工具(如axure、墨刀、visio等)设计产品原型的时候,需要明确界面上的元素是什么,如何展现,鼠标移动或者点击上去是怎样的效果。

2、数据逻辑

这一点往往也是非常多创业团队和新手产品经理容易忽视的。比如一个直播列表界面,上面有三个tab,分别是关注直播、热门直播、最新直播,那么最新直播是基于怎样的数据逻辑获取的,你就需要在你的原型设计上进行说明了。当然,最新直播的数据获取逻辑是比较简单的,也许你不和研发人员说明清楚,他们也能知道是按时间倒序排列;但如果碰到稍微复杂一点的数据逻辑呢,就比如刚刚说的关注直播的数据获取,是获取关注的机构的直播呢,还是获取个人的直播呢,这都是需要说明清楚的。

3、操作逻辑

一个原型界面上可以进行操作元素的有哪些,哪个可以点击,哪个可以选择,操作后出现怎样的反馈,比如弹出浮层?进入新页面?或是跳出新页面?还是给一个怎样的提示? 这些也是需要在原型设计里面说清楚的。

这三个点是一份完整的原型设计基本需要包含的东西,再配合上之前画好的产品结构脑图和流程图,就基本可以与开发进行轻松愉快的交流了。只有这样,开发者才能明确这个原型设计的开发需求,而不是让开发工程师自己去猜,去揣测数据逻辑、算法应该是什么样的。

如下图,可以在原型设计上做相关的注释说明:

产品经理究竟该如何进行原型设计(上)

谈谈产品需求文档(PRD文档)

很多公司都要求产品经理写产品需求文档,我们来看下一份完整的产品需求文档包含哪些部分:

产品经理究竟该如何进行原型设计(上)

产品需求文档内容

通常来说,产品经理往往不会写的那么详细,能够覆盖到前面四个部分便已经算是一份基本合格的产品需求文档了。

我们一起来看下文档里面都具体包含什么内容:

1.概述

概述部分是概括地说明产品背景、产品目标等。

1.1产品概述及目标—-包括背景介绍和产品目的

1.2名词解释—-声明文档中出现的名词含义

1.3数据词典—-介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。

1.4文档阅读对象—-声明本文档输出的阅读对象和注意事项

2.产品描述

产品描述介绍了产品的整体逻辑流程,概括性的描述产品需求、产品版本规划、产品整体的框架结构以及功能列表。产品整体流程与产品框架都需要使用相应的图表展现方式

2.1产品整体流程-—展示产品框架图和用户流程图。

2.2产品需求描述—-描述产品核心功能,解决哪些情景下的哪些需求。

2.3产品版本规划—-叙述产品版本迭代计划,版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。

2.4产品框架—-展示页面层级及备注信息

2.5功能列表—-展示产品功能名称、对应模块、功能说明、备注等信息。

3.功能描述

功能需求这部分需详细描述产品所涉及的各个功能点。将整体框架拆成数个独立的功能点,分别描述每个功能点的逻辑流程图、界面、字段说明以及业务说明。统一采用Use Case的方式进行描述。

3.1流程图

3.2界面原型

3.3字段说明(包括数据字典)

3.4业务说明(Use Case)

4.非功能需求

非功能需求,也就是关于产品的其它方面的要求。

4.1安全需求

4.2统计需求

4.3性能需求

4.4可用性需求

产品经理究竟该如何进行原型设计(上)产品需求文档

嗯,我们已经看到了常规的产品需求文档长什么样了。有一次和一个朋友聊天,说起他们公司的产品需求文档,是一份长达200多页的word形式的产品需求文档,其实这样的文档看起来相当费劲,也不容易更新同步;

很多开发人员和产品经理之间产生的矛盾,其实都是因为这份又臭又长的产品需求文档。因为无论是谁,都不喜欢看这么长的文字,开发人员其实根本不需要这份文字式的需求告白书,他们喜欢“看图”,这种文字式的需求文档应该是产品经理脑中的思路,而不应该直接把思路描述成文字转交出来。其实我个人也不喜欢这样的风格,沟通成本太高,所以对于创业公司而言,还是尽可能简单直接有效最好。 做好如上几点,对于大部分产品沟通场景来说,应该就可以满足。

所以,通过输出产品结构脑图、产品流程图、界面原型就可以替代一份产品需求文档。

ps:如你所见,这是关于产品设计的系列文章,教你如何从0到1设计一款产品,如对我的文章有更多想法和意见,欢迎关注我的公众号找我交流。

作者:壹百度(微信公众号:倒退集),在线教育企业服务领域产品经理,创业公司Team Leader。常常自诩是文艺青年和极客青年的结合体,在宅与不宅之间可以自由切换,曾主导多款重量级产品的产品策划和设计工作。

(编辑:济南站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读