产品经理和原型设计不得不说的故事

作为产品经理,一直认为原型设计应该不仅仅是设计师们的工作,也应该是产品经理的工作——尤其是在前期需求讨论阶段。

一个产品的骨架与灵魂,是由产品经理赋予的;血与肉,是由研发工程师赋予的;五官、四肢是由设计师们赋予的。然而,在还没有血肉之前,如何为团队成员勾勒出一幅完整的“骨架”,就是产品经理必修的功课了。因为这副骨架勾勒的如何,会直接影响团队各岗位同事对于需求理解的一致性,有效减少因为理解差异带来的无意义PK;同时,能够直接影响前期需求沟通和讨论的效率,帮助团队尽快针对需求达成一致。

综上,这副需要勾勒的“骨架”图,就是产品经理需要做的原型设计。

·正文

爱因斯坦说,if I can’t picture is, I can’t understand it.

大多数时候,产品经理们都能picture出自己的产品设计思路,但从某个角度来说,产品经理需要做的工作,比爱因斯坦要困难的多。毕竟相对论不是每个人都能看懂,而产品经理的原型设计却需要保证团队中不同岗位、负责不同工作、知识结构各不相同的每个成员,都能够完全的understand it。

因为前期需要和各个岗位的同事沟通,也就决定了产品经理所做的原型设计需要具备以下特点:

1. 低保真、高效率 —— 不必投入太多精力在美观和交互逻辑上,只需要表达出核心页面和功能即可;

2. 易修改、易传播 —— 能够方便的进行修改补充,同时可以轻松的导出、共享给项目团队所有人;

已有的常见工具中:

白板+笔、windows——的确低保真和高效率,但是不能方便的传播和随时修改;

excel、visio——它们更适合在需求确认之后,将功能逻辑按照规范做标准化的文字描述;

powerpoint,Photoshop——它们太低效了,往往投入大量时间做了powerpoint讲起来是既没有power也没有point……

综上,在这个需要和各岗位成员沟通、需求阐述与确认并快速迭代的过程中(如下图),产品经理的原型设计必须“高效完成、易于演示、并保证所有成员完全理解”

正所谓,工欲善其事必先利其器。

诚然,我相信小米加步枪也能取得革命的胜利(曾见过有高人用excel也能作出令人乍舌的原型设计),但是,选择一款适合自己的原型设计工具不是更好?

接下来为大家推荐一些适合产品经理用的原型设计工具:

· web原型设计工具

1. Axure
http://www.axure.com/
http://www.axure.org/

Axure已经在太多的场合被太多次的提起过,在这里不必多言。

优点:
组件/实例资源丰富;see it happen——近乎完美的演示
缺点:
学习曲线陡峭,需要投入较多时间;个人认为不太适合产品经理使用,当然还是建议刚入行的同学花时间学一下。

2. GUI Design Studio
http://www.carettasoftware.com/guidesignstudio/

如果把Axure比作原型设计中的Photoshop,那么GUI Design Studio就是windows 画图板了

优点:
简单、小巧、易学、易用;原型模拟演示功能丝毫不逊色于Axure

缺点:
更专注于windows 桌面软件的原型设计,对web、手机端设计帮助有限;中文破解版功能有缺失

3. Pencil
http://www.evolus.vn/Pencil/Screenshots.html
https://addons.mozilla.org/en-US/firefox/addon/8487

Pencil是一款以FF插件形式存在的原型绘制工具,如其名一样简单,适合用于web原型快速绘制。

优点:
FF插件形式运行;简单、小巧、快速、方便

缺点:
组件库较小、功能有限

4. Mockingbird
http://gomockingbird.com/

Mockbird是一款在线原型绘制工具,组件丰富,使用于web端、手机端产品设计。

提供了完全基于浏览器窗口的产品原型设计服务,采用了Cappuccino的JavaScript开源框架,能够较为逼真的模拟 Axure 这类桌面软件,给用户极大的亲切感。No Flash, No IE, All in Canvas, Apple Style!

优点:
在线即可使用,加载速度快;组件较为丰富、可在线保存

缺点:
不支持IE,对Chrome支持的不好;输出的PNG不支持中文

5. Mockflow
http://app.mockflow.com/mockflow/

Mockflow是本次需要重点推荐的工具,同样作为在线版本,其丰富的组件友好而强大,并且支持一个在线共享的组件库!十分适合web端与手机端产品原型设计。

优点:
组件库及其丰富,界面炫酷;在线版运行流畅、强大的右键菜单;支持中文、多文档在线保存

缺点:
在线版保存有空间限制;演示功能略逊于Mockups

·手机软件原型设计部分

1. Mockups
http://www.balsamiq.com/demos/mockups/Mockups.html

Mockups是一款设计师为了自己工作方便而开发的个人软件,开发者本人都没有想到手绘的风格和简单的组件能让该软件如此受欢迎,实际上它最吸引人的地方是完美的演示功能。

优点:
为手机端原型设计而开发,模拟演示功能十分强大;风格很萌…

缺点:
基于Adobe AIR,文件尺寸较大时软件性能表现一般;对中文多字体的支持比较差,不支持插入图片。

2. iPhone Mockup
http://iphonemockup.lkmc.ch/

iPhone mockup 是一款更专注与iPhone上软件原型设计的工具,提供了iPhone上常用的全部组件。

优点:

支持在线协作,同一设计可由不同的人修改;iPhone设计组件丰富,并提供手绘和标准两种风格

缺点:

功能比较少,不支持导出到图片文件,不支持演示;

3. Lumzy

http://lumzy.com/app/

Lumzy是基于Flash/Flex平台上的产品原型设计软件,其组件同样适合做手机端原型设计。

优点:

界面友好、功能丰富;支持图片插入,预览、导出功能;支持手绘、mac、win三种风格切换。

缺点:

适用于手机的组件不如前两款丰富。

4. iPlotz

http://iplotz.com/app/index.php

与Lumzy相同,iPlotz也是基于Flash/Flex平台的在线原型设计软件。

相比前者,iPlotz提供专门针对iPhone的组件库,同时有非常强大的项目/时间管理功能。

优点:

同Lumzy,包含iPhone专门组件库,支持html预览和导出。

总结&建议:

没有最好的工具,只有最适合自己的工具。只要能高效、准确无误表达设计意图的工具,就都是好工具!

先用纸笔手绘,勾画出产品整体架构;之后再做原型设计。

先用工具做出最常用的组件,并将其group&lock&save,这样可以节约很多时间。

· 结束语

最后,分享几点工作中的个人感触, 与大家共勉:

产品经理并不一定是专才,但应该尽可能做到全才;即便是全才,也不是神,请充分信任伙伴;团队里肯定不会有猪一样的队友,所以请不要把自己当作神……

要充分信任设计师的专业能力,时刻牢记自己代表的用户,团队里其他成员也是用户;不要过分受自己主观的影响而质疑甚至挑战设计师的专业能力。

把需求理解的不一致消灭在产品经理的原型设计阶段;解放设计师,让他们全力投入到需求确认后的设计工作中去。

让我们接过设计师们的枪,一起 ·华·丽·的·战·吧!

本文来自:http://djt.open.qq.com/article-114-1.html

时间: 2024-09-13 07:22:52

产品经理和原型设计不得不说的故事的相关文章

产品经理和原型设计之间的故事

作为一名产品经理,我一直认为原型设计应该不仅仅只是设计师们的工作,同时也应该是产品经理的工作--尤其是当处于前期需求讨论的阶段. 而一个产品的骨架与灵魂,通常应该是由产品经理赋予的;而血与肉,则是由研发工程师赋予的;五官.四肢是由设计师们赋予的.但是,在还没有血肉之前,应该如何为团队成员勾勒出一幅完整的"骨架",我想这就是产品经理必修的功课了.而因为这副骨架勾勒的如何,将可能会直接影响团队各岗位同事对于需求理解的一致性,有效的减少因为理解差异带来的无意义PK;同时,又能够直接影响前期需

Web应用的成功之路 – 产品早期的原型设计与用户测试

最近一阵有些难以抑制的脑痒手痒,阅读和码字的欲望也渐增:却受时间精力等绝对客观因素所限,不得不维系一周一篇译文的频率,感觉多少有那么点沮丧和无奈. 关于本文,其实在标题上犹豫了蛮久.这篇内容是新书A Practical Guide to Web App Success的第15章:主题显然应该在Web应用方面,但是本章单独拎出来看的话,却又适用于各种常见类型的Web产品.whatever,不矛盾.作者Dan Zambonini在本文中将向我们阐述Web应用在原型阶段的设计与测试工作的重要性,并从实

Web应用的成功之路 产品早期的原型设计与用户测试

中介交易 SEO诊断 淘宝客 云主机 技术大厅 最近一阵有些难以抑制的脑痒手痒,阅读和码字的欲望也渐增;却受时间精力等绝对客观因素所限,不得不维系一周一篇译文的频率,感觉多少有那么点沮丧和无奈. 关于本文,其实在标题上犹豫了蛮久.这篇内容是新书A Practical Guide to Web App Success的第15章;主题显然应该在Web应用方面,但是本章单独拎出来看的话,却又适用于各种常见类型的Web产品.whatever,不矛盾.作者Dan Zambonini在本文中将向我们阐述We

Web应用成功之路 产品早期的原型设计与用户测试

中介交易 SEO诊断 淘宝客 云主机 技术大厅 最近一阵有些难以抑制的脑痒手痒,阅读和码字的欲望也渐增;却受时间精力等绝对客观因素所限,不得不维系一周一篇译文的频率,感觉多少有那么点沮丧和无奈. 关于本文,其实在标题上犹豫了蛮久.这篇内容是新书A Practical Guide to Web App Success的第15章;主题显然应该在Web应用方面,但是本章单独拎出来看的话,却又适用于各种常见类型的Web产品.whatever,不矛盾.作者Dan Zambonini在本文中将向我们阐述We

产品设计职位谈:让人欣赏和让人厌恶的产品经理

文章描述:产品设计职位谈:让人欣赏和让人厌恶的产品经理. 我大概见过厉害的产品经理.例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 欣赏的:理解产品的灵魂 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.他们不管做什么决定都能讲出不少理由,而且还让我觉得挺客观挺

《妥协的完美主义:优秀产品经理的实践指南(卷二)》一第1章 App产品设计团队进化史1.1 在没有产品设计团队的软件开发时期

第1章 App产品设计团队进化史 妥协的完美主义:优秀产品经理的实践指南(卷二) 在App的开发过程中,常常有两股主要矛盾力量:开发人员和市场人员. 尽管市场人员精通市场.定价,善于掌握商机,但他们对产品设计和过程的要求,只局限在需求列表.需求清单上,列出他们所需功能,这些需求同用户的实际需要和期望有一定差距,主要在于如何超越竞争对手,如何赚取更多的利润,这些需求的来源基于市场调研和对用户心理的猜测: "市场数据的表现是这样的,用户可能是因为某某原因不喜欢使用我们的产品." "

需求变更,产品经理的良心也会痛!

引言:在项目执行过程中,产品经理与后续的合作团队,包括设计.开发.测试等相关人员最尖锐突出的矛盾,就是需求变更,这是产品经理最经常被诟病的地方.频繁的需求变更,对产品.项目进度和团队积极性都有非常大的危害.产品经理一定要不遗余力避免需求变更的情况. 本文选自<爆款是怎样炼成的:产品经理晋级宝典>. 作为产品经理,我们一定要理解开发团队及其他团队成员为什么视需求变更为大敌.事实上,需求变更对整个项目都非常有害. 需求有变更,就意味着设计.开发团队的工作有浪费.这首先是资源和时间的浪费. 这会导致

如何成为一枚出色的产品经理?

产品经理的职责是探索产品的价值与挖掘需求并分析可用性.可行性,然后联合交互设计与技术开发人员,共同定义产品的特性并将他实现.在此过程中,产品经理作为中间枢纽,需要和团队成员进行沟通合作,驱动团队执行力与提升工作效率.那么如何成为好的产品经理呢??? 以前我说过:"只要肯用心,每个人都可以成为产品经理!做一名成功的产品经理很容易,只是做一名成功产品的产品经理不容易! "因此,在成功之前我们先要成为一名出色的产品经理. 下面我将以步骤拆分,一步一步讲讲如果成为出色的产品经理. 一.想成为产

《MacTalk 跨越边界》一一2.3 最可怕的产品经理

2.3 最可怕的产品经理 MacTalk 跨越边界很久以前,PM两个字母的缩写代表了Project Manager(项目经理),那是一个软件工程横扫世界的年代,人们为了精准地完成一个软件项目,设计出了各种开发规范和工程过程,项目经理可以制定出细致到每个月.每周和每天的工作计划,最后,项目延期了-- 时至今日,PM早已改弦更张,成为产品经理的代名词,在这样一个以用户和产品为中心.设计和用户体验改变世界的时代里,产品经理被赋予了太多的职责和意义,他们主宰着产品的特征.设计.实现和用户心理,如果负责了