Friday, 22 February 2019

我所理解的产品、服务、解决方案

今天和朋友讨论到这三个概念,很多时候我们因为更明确概念而知道边界和下手的策略
这里记录下我当前所想到的理解:
1.产品服务 价值大于 产品经理服务
产品经理服务=业务方:你给我安排一个产品经理来解决我的问题
产品服务=业务方:你给我提供一个产品支持我的业务,解决我的问题

2.针对问题的确定性差异区分产品与服务
服务=产品+人工运营->提供问题解决的确定性,确定性由服务方保障
产品服务=产品+用户->能够解决问题,但确定性由双方共同保障
解决方案=多产品+多种人工运营+用户->共同解决某个大类下的多个问题集合

3.解决方案
本质:人(内部运营、外部用户)+产品(子项能力+交互操作)针对问题的不断打包和重组,重组的根基在于问题,而重组的思路在于场景、流程和人的职责划分

设计好的解决方案需要不断反复抽象、拆解(包括问题、流程、场景、产品、人的关系),大部分时候产品、能力的重组好理解,而人的问题难理解、需要一定的对人理解的经验,导致解决方案中容易缺失一部分,形成问题的确定性。

Saturday, 28 April 2018

一次内部产品启动沟通小结

最近团队调整,想要重新做一款内部平台(是一个先期假设),老板要求一个月内描述清楚这个产品,并对内进行沟通。
这就带来两个关键词“内部平台产品”“沟通”,做习惯了对外的产品,你会发现其实内部产品的描述是另一种风格,思考基本框架虽然相似,但面临的问题和挑战却有一些不同,导致一开始找不着北。

当然我也可以说其实整个过程和做产品很像,只是我们自己很多时候没有意识。

Continue Reading

Friday, 8 August 2014

更加现实的“极致”

上次小说了一下雷军同学的七字诀,诚然这几个字近乎完美,但完美的问题就在于现实中可能太过于理想化。也许我还不是一个极致到位的人,所以更多时候选择现实的极致。
记得去年我就单独和Boss(PDM背景)聊过,如何打造极致的产品。对话过程参杂有太多感性因素就不在这里多废话。

Continue Reading

Friday, 1 August 2014

随机是个好元素

前几天在朋友圈看到 围住神经猫(试玩链接)的小游戏,一夜之间几乎被刷屏,单就效果来说可以说做的非常好。

这不,今天又看到两个简单的微信游戏:

1.疯狂手指(试玩链接)–如法炮制传播手段,狂点手机屏幕看你十秒钟内能点多少次

2.看你有多色(试玩链接)寻找“色狼”,其实就是娱乐性更强的色彩测试

Continue Reading

Saturday, 21 June 2014

有关用户体验

大半年没有写过一篇文章了,罪过罪过。

作为一例PM经常被询问或者PK的词语就是用户体验,经常反思但总是没有时间整体总结下我所理解的用户体验” 

整体来说,用户体验是理解认知,心理感受,功能操作,场景连续性,防止过份干扰用户等共同作用的结果!

之前有见过一种说法是把用户当傻子,一直觉得这句话欠妥,虽然能使PM在初期简化思考方式,但不容易形成更深刻的产品/体验认识。换句话说,只比一个普通的爱好者好在群体普遍性的理解!虽然每个产品每个细节都做成这点的人都不多,包括自己在内,还是得这样说!

Continue Reading

Monday, 19 August 2013

设置操作的总览原则

越来越多的所见即所得的设置操作充斥在我们的产品中。
优点自不必多说,大量的用户能够直观的对所看到的内容进行修改/设置,让体验更加优良
但随之而来的问题是,一般的产品中对于设置 都会有一个总的入口,这个入口中是否还需要保留那些已经在其他地方被“所见即所得”的设置么?
这里我的理解是,需要(除非总入口无法承接该设置的体验)。
原因也非常简单:
1.保证全部设置的可见性(在web端产品中,很多设置 为了美观 是在mouse over时出现的,未必所有人都能看得到)
2.保证设置的全局性(当用户游走在各个页面中时,不要指望用户一定能记住任何设置功能在不同位置的展现,用户只需要知道至少有一个地方他能找到所有的设置方法即可,这样不仅有益于用户对设置的入口的统一认知,还可能拓展用户对其他不常用的设置的理解)

Continue Reading

Friday, 16 August 2013

让用户认知页面还有更多

早期做APP产品时涉及功能较多,而运营型内容较少,基本内容都是一屏可认知的情况,没怎么考虑过对于用户的整体视觉感受而言,是否能够意识到网页/页面区域还有更多内容的理解方式。

最近在做的一个项目,需要对重点内容着重展示,占屏幕整个区域80%以上,这样就很容易导致用户看完页面后,下意识认为,当前页面已经没有内容了而选择关闭,无法向下继续浏览。 Continue Reading

Tuesday, 13 August 2013

关于主线需求与支线需求的设计

在产品设计过程中,经常会遇见各种不符合主线需求的特例(这里不讨论主线需求是否合理)。刚开始做这类设计和逻辑规划时,很可能遗漏特殊情况,经别人提醒后才发现!

这里就有一个很经典的设计原则:抓大放小,特殊逻辑特殊处理,实在无解的果断放弃,不影响主线流程体验为优先。

其实说起来很简单,但真正用的时候,很可能因为各种当事时(比如和其他同事争执不下)的想法而导致最终的设计让主线流程变得异常复杂,繁重!

比如收藏图书这样一个流程:

假设对于产品而言,收藏图书不区分文件夹是主要需求,而收藏图书并建立不同的书单属于特殊需求。那么,主流程应该是用户点击收藏按钮-收藏到用户的默认书单中-收藏完成,在完成提示时告知用户可以选择放到不同的书单,用户可选择即可!而不是用户点击收藏的时候就询问用户到底放到哪个书单中!

Thursday, 8 August 2013

产品设计中的对比论

最近使用了几次“对比”的设计思想,正好适合现在记录,一来对后续设计进行检验,二来算是对之前的小结

“对比”的设计思想从大而言,可以影响整个产品的设计初衷,比如 比价类产品。从小处着手 可以引用至产品涉及的细节文案,比如 一个相册默认情况叫做“公开”,那私密的情况应该叫什么?

不论大还是小,追根溯源“对比”的设计思想都是以用户的诉求为核心的,只不过这是一个简单可遵循的套路而已。 Continue Reading

Wednesday, 8 August 2012

张小龙的《微信背后的产品观》学习记录–《需求篇》

4A00BBC98FB636528417C3F3A69D35F5_B500_900_500_133

方便记录,写下更新时间 08-09/02:01

《需求篇》
————————————————————————
对新点子,99%的情况下否定是对的
yy用户的需求很常见,大部分yy也就是yy,不是真实的需求
不要用户说要什么就做什么
用户的需要是零散的,他们的反馈只能帮助你了解他们的想法,而PM需要对这些反馈进行归纳抽象,找到问题本源。(我想要一杯水,如果不知道用户是想要给鱼池换水而已,很可能给的是一杯热水) Continue Reading