体现中俄双方合作_产品小白须知:如何用原型体现你的专业度?

笔者谈了整体描绘原型的要点和通过描绘原型如何表现产品经理的专业性。

体现中俄双方合作

面试产品时,面试官说:“作为产品经理,你认为你的专业性是如何体现的? ’问过。

只是画试验品和写文件,1年和10年的产品经验,实际上没有什么区别。

之后,在工作中,经常想起这个问题,反省“作为产品经理,应该怎样表现我的专业性呢”。 我也有一些自己得到的教训。 我们以后再谈吧。

今天主要是产品的入门者,如0年到1年的产品经理。 如何解决尽可能完善原画原型的问题,不会因遗漏过多而频繁地被Diss。 如果你恰好有这个混乱的话,OK,只要看这篇就够了。

一、比画的原型更重要的是,想在画画之前知道想做什么

许多白刚入门的时候,包括我自己在内,特别重视体验,特别是细节的交流,页面的展示,感觉好的产品外表完美,内在应该很有魅力。

实际上,这种状况发生的概率高的是这个阶段的产品经理,除了外部体验层以外,商业流程、基础逻辑、商业模式等高的内容什么都说不出来。

我有一个建议。 白色可以帮助你提高一点。 必须有意识地把自己变成以目标为导向的产品经理。

无论是负责功能模块,还是负责整体项目,你每一步行动都一定有明确的目标。 我觉得不应该怎么办而是更好。

注重目标可以从细节中提取,帮助您将注意力集中在整个过程中的关键节点上。 从宏观角度来看问题的产品经理一定比从微观角度来看增长得快。

即使是画原型,也不要在意是画草稿用纸还是用Axure/Sketch/墨刀,请找到自己觉得方便的东西。 不必太重视。 工具的目的不是深入学习使用工具,而是提高使用效率。

所以,在画原型之前,在你的脑海里清晰地描绘你的什么,每个你的主页需要哪些要素,主流是什么,原型只是将你的想法可视化。 因此,产品经理的价值为99%,原型为1%。 现在,我们进入绘制原型的阶段。

二、绘制原型的程序和检查清单

在谈到这一部分之前,我有两个想法。 产品经理必须尽早知道,即使是最严格的产品经理,也无法输出水滴不会泄漏的原型。 所以,原型输出的时候,错过是不寻常的事情。 要接受它,就不必因此而否定自己。 这很重要。 最终影响产品/功能成功与否的,是您是否打中用户的要点,是否解决了用户的问题。 因此,他们在主流程的关键节点上花费了大量精力。 除非主流经常改变,其馀的都是小事。

因此,画出原型,第一步就是直接画出主流,其馀的就是洗出补充不足,变成比较完美的原型,是专业表现的第一步。

主流不怎么说话。 如果产品的白主流有问题的话,即使说明基本的业务能力,这里也不知道。 其次,重点介绍从什么方面发现了补充不足。

1 .列举页面的所有要素,有明确的规则和说明

这是产品设计打印文档时的习惯。 一一列举,可以防止细节遗漏。 特别是对于产品的明白,可以这样开始你的工作之旅。

2 .考虑文本的最大数行、最大字符数的界限、超出界限应该如何处理

即使在信息化的今天,文字也是最核心的表现内容。 因此,对于黑文字,当然需要考虑黑文字的行数/黑文字数/界限值来进行处理,只要能够形成约束俗成的规范即可。 否则,考试会被这些小问题逼得很尴尬。

3 .页面上的每个元素都必须明确是否支持动态配置

考虑到未来的可扩展性,每个功能区域是否受到动态控制,元素内容是否可以灵活配置,副本是否支持动态更改。 所有这些都需要在产品设计时加以考虑。

当然,一般来说,保证不能动态配置,如果需要动态配置,就必须明确表示。 否则,如果你最后想改变,就不那么容易了。

4 .考虑可触发区域的状态:状态因业务场景而异

主流一定是正常的状态,但状态会因业务场景而异。 例如,最基本的触发可能性、不可触发以及对于主过程的所有表明不同业务状态的事实将作为对主过程的信息来补充。 业务状态:行为发生前/行为发生中/行为发生后的数据状态:有数据、无数据时间状态:未开始/进行中/过期

5 .考虑设备、版本和平台三个系统级别的影响

设备:是否与平板电脑、小型手机兼容,是否有纵横的画面切换。 基本上就是这两个要点。

版本:这很重要。 因为很多产品白很容易忽略。 设计的产品是否与旧版本的使用者相容,不相容是否会影响旧版本的使用者。 如果需要兼容性,是否支持当前设计,是否需要强制升级。 特别是在进行以往的功能优化再构筑时,有必要更加慎重地考虑这个问题。

平台:这种想法在H5开发中很常见。 由于需要适用于多个平台的代码集,因此需要考虑H5和APP的平台差异。 例如,返回方式、共享触发、体验的顺畅度。

6 .是否需要初学者的指导,改变视点看功能

是否要求新用户了解新功能,并指导其立即可用。

7 .头疼网络问题也是需要考虑的因素之一

设计适当的解决方案,考虑一系列情况下可能发生的场景,例如网络缓慢、网络加载过程中的加载超时、中断、重新加载、4G和WIFI交换机。 当然,这个做了一两次之后,一般来说可以形成一般的网络处理方式。 关于这样的全球页面的规则,单独拿出来比较清楚。

8 .登录状态和用户角色

考虑您的业务是否需要区分登录用户和游客,何时开始登录? 业务用户角色是否具有多样性/阶段性。 多样性在平等维度中是指不同的角色。 护士、医生等。 阶段性,例如一般用户、VIP用户等。

9 .反馈的注意机制是否完善

例如,常见的toast反馈提示、二次确认机制等。 这个不说明。

10 .是否设计过度,各要素是否为必要要素

从用户的角度来看,整体功能是否能够使页面的各要素为必要要素、是否有为设计而设计的疑问、是否实现了MVP、整体功能更简单。

基本上,制作上述金十条,会大幅度降低你做成Diss的概率,下次画出原型之后会产生很多后遗症。 因为原型只是第一步,所以如何让众多相关人员认知原型,能够根据原型输出预期的产品效果是最重要的一环。

三、描绘原型后遗症,最佳解决办法

需求交货后,改变作为产品最普遍环节的需求。

改变需求不是禁忌,原因很多——或者是业务调整,或者是自己的疏忽,或者是boss的突然奇想太多,是正常的。

而且你的产品实际上是Diss,不能说是80%。 至少50%不是改变需求本身,而是改变需求的同步和处理方式。

那么,这个数据也是拍头决定的,如何解决这些后遗症很重要。

以下是一些实用建议,出自本人总结的眼泪教训

1 .变更某个地方的话,一定要着眼于整体,充分考虑这个地方对整体的影响

这至关重要,尤其是在需求审查-提交后,如果有变更,第一个时间一定会考虑到影响面。 还有影响,核心开发人员需要参与评估。

2 .涉及后端控制台的设计,首先可与控制台用户(大多数是运营商)取得联系,最终直接与服务用户接触

这可能没有什么参考意义,但是一步一步地,如果运营者的操作能够做出顺畅的内部配置控制台,那么本身就有助于产品的生产效率的提高。

3 .产品没有标准答案,但绝不含糊

画出原型后一定会有很多不确定的地方,所以必须事先决定——从目标来考虑,也可以参考竞争品。 和同事商量,不要由老板决定。

但是,避免了歧义,没有明确的结论。

把结论交给研发、测试来推测、弄瞎,是产品最愚蠢的决定。

产品给予用户可靠性。

这很重要,包括与您合作的UI、研发和测试,这些用户是衡量人是否可靠的重要因素。

4 .改变与所有人同步是原型输出后的优先级最高

当需求触底时,意味着原型进入执行阶段。

在执行阶段有变更,比变更本身更重要的是如何同步,否则后期的撕裂是无限的,你也印着非专业的标签。

同步方式,至少可以追溯到当时的忘记之后,写成原型/写成说明/发送给组@相关人员。

请放心。 一定是有人没看见而错过了。 因此,最好用邮件同步相关人员,小组注意。 大家因为变更不同步,所以感情比变更本身要大很多。 所以,不需要担心被贴上频繁变更的标签,第一步是确保同步作业。

变更的影响小的话,当然OK,同步后很开心。 如果改变了主要的程序,为了能够影响预定表,必须立即与研究开发进行谈判。 这对于控制整体的进度很重要。

5 .产品经理应该有点锋芒,学会否认他人的想法

在这个产品经理横行的时代,如果你按照上述顺序做自己应该做的原型工作,依然会有不满和不满,对你的原型内容抱有疑问。

请不要害怕。 产品对成本最低的工作抱有疑问。 吐槽疑问再次不正常,只要合理,谦虚接受。 如果不合理,就直接否定。 这个职业,本身应该有点锋利。

结束

那么,这篇文章就此结束。 回顾产品经理的道路,可能很多人最投入精力的是描绘原型和反复。 所以,明白的话,就可以读,提高自己的基本工作,成长起来。 否则,可以阅读,对照自己的日常工作,提高专业性。

希望这边的文章尽量减少因为我被告知Diss而被告知Diss的次数。

新年快乐!

本文@御风发表原件的都是产品经理,未经作者许可禁止转载。

主题图来自UNSPSSD,基于CC0协议。

大家都在看

相关专题