为什么我总是一边设计原型,才能一边想到产品的功能?

刚入行不久,感觉每次设计原型前都会写一大堆分析,但是脑海中没有实际的界面布局应该怎么样。边做原型边思考这里是不是应该加个什么,那里是不是应该加点什么,不停地改,一个小功能总是做很久才能提交。我是不是不
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 55 浏览
  • 略问用户 提出于 2020-09-26 14:09:25

33 个回答

xxxxxa

说在前面:在产品经理工作中,原型设计工作占比很少,且是靠后的。

首先,确认需求范围和目标:你要和相关需求部门确认当前版本的需求范围和版本目标;

其次,功能清单/功能架构:你要自己先列出功能清单,然后在列的过程中,有不明确的,需要再次和业务方确认,同时你还要与技术确认以下实现的可行性

再次,梳理相关业务流程:针对当前版本的核心业务流程,要提前梳理出来,有问题或则不明确的继续和业务方及技术确认和敲定

最后,你再去看一些竞品,然后再画一些原型草稿;

这过程中,看到没,我一直再保持与业务方、技术的高频次沟通,这样做的目的,是确保你的需求信息是实时与各方保持一致的,且推进也会很有帮帮助!

以上纯属个人拙见,仅供参考!

请先 登录 后评论
xxxxxa

做产品是一个需要练习的行业,来一个故事板,情况可能就会好很多。

分析来分析去总是宏观。一旦要做落地,就要有清晰的用户画像和确定的需求描述。

故事板将需求从抽象具体化

  • 角色
  • 场景
  • 情节

故事板作为一个表达工具可以让你有代入感、同理心,不知不觉你的故事就可以把整个业务流程整理出了。

比如中午饭点,外面下雨,宿舍老王(大学生哈)想吃饭却不想出门,他打开手机,启动XX外卖,选择附近美食,筛选新店优惠......最后外卖送到了手上。

一个故事板,用语言或者可视化的方式把用户故事、业务流程、产品功能、具体操作都讲的清清楚楚。

如此,从故事到产品流程、相关功能、具体操作,可创造的东西就变的非常少了,各类功能,操作的设计页面业界有太多可以参考的了,多看即可。

请先 登录 后评论
xxxxxa

画原型,在产品的工作里可以类比为装修时候摆放家具。

想象一下,新买的房子,想要能够达到拎包入住,我们需要提前做些什么?

1,确定装修风格;

2,确定房子的尺寸,对房子装修的布局心里有数;

3,确定要买的家具,整理好采购list;

4,规划好怎么采购,搬家顺序;

5,买家具,摆放家具;

对应产品的工作步骤,就是:

1,确定装修风格;——确定版本的目标

2,确定房子的尺寸,对房子装修的布局心里有数;——确定产品的边界,mvp是什么                 

3,确定要买的家具,整理好采购list;——确定功能清单

4,规划好怎么采购,搬家顺序;——梳理流程,梳理逻辑

5,买家具,摆放家具;——画原型,将需要的功能组件画出来

比喻可能不一定精确,但是意思是这么个意思。画原型只是产品工作中很小的一部分。产品经理更大的价值在于,确定产品的走向,定义产品的价值。

至于你说,总是画原型的时候边做边思考需要什么,很可能是因为:你把太多的工作重心放在画原型上,以为画原型就是看看竞品,照着抄。所以容易造成的现象就是:直接一上手就画原型,然后看看七七八八的竞品,发现有的竞品有这个功能,有的竞品有那个功能。所以你画原型的时候就会很纠结,一直想要不要加这个,要不要加那个。

建议多思考一下产品的价值。

请先 登录 后评论
xxxxxa

我刚开始做产品的时候也这样,后来发现是自己思路的问题,以下几点对我挺有帮助:

1、尝试在需求分析的阶段用思维导图或流程图来理清业务场景、功能点、业务逻辑;

2、培养自己的产品思维,总结一套自己分析问题的方式:比如可以再PMCAFF多回答几个问题,然后对照自己和其他人的答案,看自己有什么没有想到的点或欠缺的地方。

3、多看看其他的产品,熟能生巧,等到对某一类产品很熟悉了,不用想就知道一个需求会带来哪些影响,不管是界面还是背后的逻辑。

请先 登录 后评论
xxxxxa

产品在公司里算是最水的一个人。说业务,他们业务能力一般般(甚至很差)没有市场部的同事理解用户需求。说技术,不懂代码原理的产品大有人在。说测试,啥玩意儿?说运营,可能都不知道要干嘛。

但产品却是公司里最重要的存在,以上提到的他可能不是最懂得,但多少也要懂一点,原理也行,怎么操作也行,而且要很好的把它们梳理到一起,以一个所有人都能理解,懂的方式去描述给其他人。

其实你提问的时候,你自己基本就知道是什么问题了。你自己也说了“边做边思考”,你都还没想明白,你就开始做,最后的结局应该能猜到吧。不管是写文档还是做需求,原型设计图,永远是放在最后的,这是有道理的。你先想明白这是什么,在思考怎么做,然后再做。想明白这是什么:需求是啥,要解决的问题是什么,为什么有这么一个问题。。等等一系列背景,问题,解决方法(有没有其它方式解决)。怎么做:怎么加进现在的产品设计,之前设计的功能能不能同时也把这个问题解决了。。等如何能融入自己产品的思考。做:流程图(我喜欢用流程图把功能的流程画下来),时序图(把前端、APP、系统、用户之间的交互画出来 看看之间还有什么遗漏),原型图。

我的流程其实是了解需求,思考功能 同时 手画流程图和时序图。再最后正式画图。各个功能点要想到,脑洞大开,能不能实现再说,先记下来。原型 永远放在了最后,因为你画的原型其实只是给UI看的,一般来讲你把框架弄好,后面就靠你们的画师了,反正让他做自己的事情就好。

你也不要太着急,一开始业务不是很懂的时候是很正常的。你公司有人带的话就多问问,没人带那就多去问问不同岗位的同时,而你公司愿意让你做产品也肯定有深层的原因。做的慢不是问题,国外一个功能的更新或者新功能的诞生,都是按月算的(除了bug之类的影响产品质量的问题)。国内以速度为主,所以你要快,但是快,就肯定有问题(只要产品能跑通,并且不严重影响产品)。

你说的事情,对我来讲是个很正常的事情,而且我也有过这种迷茫期,甚至比你严重点。但我还是在做,因为产品最重要的其实就是脸皮要够厚。哈哈哈

请先 登录 后评论
xxxxxa

首先,你不是不适合产品,这个没有合不合适之说,只有愿不愿意。

其次,每次画原型才想到功能是个坏习惯,新手常犯,所以还没上升到怀疑自我。

其他人的回答有一些说的很详细了,你可以看看,如果一开始做不到的话,可以先用下面的方法过渡下:

1、写出本次需求的要求;什么人提的需求,提了什么,为什么这么做,怎么做才能实现;

2、画出实现这次需求要新增的功能、修改的地方、涉及的页面;

3、把功能之间、页面之间的流程画出来;

4、先在纸上开始画一个个功能的原型,手绘的。

5、手绘完一个原型后,对比【2】结构图、【3】流程图核对一遍,没问题就进入下一步,有问题就看是修改原型,缺少了功能就补充相应的结构图、流程图。

6、按着手绘的原型,在axure里画好原型。

这个方法适用于那种“不画原型我就想不出功能”的新手,毕竟手绘快。等到了第三步可以直接在脑海里相出原型时,就可以省略第四、第五步了。

请先 登录 后评论
xxxxxa

想确认你说的【提交】,是指什么?

如果只是一个系统,你先做原型,在过程中发现问题,添加功能再改原型,大几率是你对业务不熟悉,因为熟悉的人,真的就是随手一画,就是可用和满足需求的了

如果是一个 完整的产品,那建议先整理一下思路,文字或者脑图都可以,形成脑图

然后,原型不用太用心去画,一开始,草图就好了,然后模拟使用过程,你会发现,真的会有调整的部分,并不是所有原型都是一步到位的(能一步到位的大神在回复里貌似有,可以求一下方法)

原型确定了后,一定一定,要去补充描述,这时候,是对思路的再次验证

请先 登录 后评论
xxxxxa

我现在也有相同的困扰,从开始做产品就没有系统性,需要自己一点点的尝试,接到任务上来就画原型,导致来回返工,有时候设计出来后,技术实现时又有问题,然后再改,整个过程很苦恼,只能一点点的填坑,以至于有段时间他们都叫我坑神。

大概做了3个项目后,做原型的能力提高了,逐渐在原型设计时将问题考虑全面些了,但仍然有一些差错,纰漏。一个功能涉及到后期,又要回来修改前边的内容。终于意识到这不是一个好的工作方法,然后开始追求系统性的设计流程,然后就开始各种网上找工作经验类的视频、文章进行阅读,进行系统设计的学习,开始一步步的进行目标用户定位,需求确认,场景分析,再开始思维导图绘制,梳理功能点。绘制流程图,梳理业务逻辑,过程中又不确定能否实现的,先找研发确认,他们也会提出自己的建议,有些确实比我想的简单高效。然后才是制作原型。

我知道还没有形成自己的系统知识体系,不过在前进的路上,每一个项目都有进步,心里还是很开心的。不要轻易怀疑自己,找到方法就可以嗖嗖提高了。祝安好~

请先 登录 后评论
xxxxxa

说一下在画原型前做了什么分析吧,而且还不知道楼主做的是APP还是WEB,是C端还是B端

我认为这可能是两方面问题:

1、场景不够明确,没有想好当下我为用户解决什么样的问题,提供什么样的服务或者功能,预期是怎么样的,从而不停的发散。这个常出现在APP端,要想清楚用户的诉求,明确目标,无关的东西或者其他场景其他关联的东西先放着

2、单页的功能比较复杂,常见于WEB端,可以考虑进行一些简单的敏捷开发管理,将能做的或者需要的功能整理成需求池,按照实际情况组合需求,形成迭代版本,也就是将一个比较大的目标拆分成一个个小的迭代,过程中可以拉项目参与人一起评审

请先 登录 后评论
xxxxxa

这本身不是制作原型的问题,原型不过是产品经理自己对外输出的思想可视化,并且这个打磨的过程就是对产品思想的维护。

所以实际上应该先形成产品理解,即这个功能本质是要解决什么问题,然后将你的解决方案实例化成功能,之后各种功能的集合形成了一个初步原型,你也就拥有了一个操作场景去优化。

但是从一开始如果你的目的性不明确,或者对问题的理解不够深入,你就会陷入对功能管理的混乱,因为你只是大概印象"我要做一个什么东西",而不是“我要解决什么/达成什么目的”,并且做出的产品各个模块的内聚性也会不好。

请先 登录 后评论