大家都很清楚，互联网产品功能开发出来只是开始，不断的运营迭代才是关键。产品设计之前，除了我们常说做的市场调研、竞品分析外，条件允许的情况下尽可能在设计前期接触用户，了解一手需求并做梳理分析很重要。产品设计过程中上除了考虑交互、功能和流程，还需要思考该功能上线后如何积累到需要的数据，为产品迭代提供指导依据，否则很容易陷入经验主义，走偏方向。产品上线后，定期的看数据、解读数据，形成潜意识的习惯很重要。
产品工作没有成型的套路可以复用和一成不变，相信每个产品人都是在不断摸索和调整，包括我自己，下面结合实际的经验，梳理和分享一些设计观点。
观点一：点、线、面，逐步分析完善需求。
点：大的需求如建一个平台，小的需求如优化某个功能点，不论大小，在开展产品设计时，可以围绕存在的这个需求点做调研、分析和思考，定义出这个点的需求是什么、解决用户在什么样的场景下的哪些痛点。如：我们在设计一个门户改版时，通过用户反馈、后台数据、竞品调研来思考是否需要改版、改版解决用户哪些重点的问题。
线：关注需求点和外围业务单元的关系，平台也好、模块也罢，它们之间肯定存在某种业务关系并在某种业务环境下为用户提供服务，将各个需求点串联起来，思考都有哪些用户会在这些串联的点上发生互动。每个需求点的业务变动会关联影响哪些其他需求点、对这些用户会有哪些影响。如：我们在设计一个接口需求时，除了解需求本身，还要了解接口外围的交互对象都有哪些、这些对象之间的关系是怎样的，以便于更好的设计需求的解决方案。
面：需求点的线条梳理完成后，将设计思路放在产品组织结构的各个环节上去审视，如：产品设计对市场、运营小伙伴带来多少业务价值（提升用户量/降低运营成本）、对技术、测试小伙伴带来哪些技术挑战和技术价值（可能的技术困难点/技术架构的优化改进）、对UED小伙伴带来哪些亟待解决的体验痛点（界面不好用/不会用）、对周边产品团队带来的业务价值，通过这层审视，将需求从用户、产品关联到组织架构，全面思考需求的价值。
观点二：解决方案有多种，需求只有一个。
需求了解清楚了，着手设计需求的产品解决方案，设计完一种解决方案后，自认为完美无缺、实则还有其他方案可以替代。尤其当解决方案涉及的点较多、业务交互较复杂时，思考出来的解决方案很容易潜意识当成唯一的解决方案，不愿意继续思考其他方案，导致陷入其中，无法跳出来。建议思考完一套解决方案，暂停休息、转换思维，反问自己是否有其他方案可以来实现这个需求，和小伙伴交流沟通。
观点三：自动化只是一种手段，不是目的。
经常看到一些产品推出一键下单、一键开通等功能，前台的极致体验对中后台的设计提出了要求和挑战，产品设计人员往往会不自然地追求这种极简方式，但回归到用户、还原用户的场景，发现有些时候，产品的自动化必须搭配人工参与的方式一起来完成，如有些用户在使用产品的过程中，会有一些线上线下的场景交互，需要在设计上做停顿和用户参与。
观点四：界面简洁和流程清晰，可以共存。
不论是面向C端还是B端、消费者还是服务提供商，只要是人在用产品就会有对产品界面信息展示和流程操作上的一些痛点需要我们去考虑和设计，界面数据的展现方式需要基于业务需求来设计流程（如是否展示正式数据和过程中数据），界面数据的组织方式需要基于现实场景来设计交互方式（如商品数量不大的情况下是按页签分开展示还是在一个页面全部展示）
观点五：数据设计和功能设计，同样重要。
产品需求分析和设计过程，对系统和功能的设计，很多设计者容易在较快时间内上手并达到熟悉和熟练，但对数据设计的思考却相对滞后甚至没有去思考，产品上线后，不清楚产品功能对用户的感知如何、是否为用户提供了较好的服务，导致产品后续迭代没有一个相对客观的指导意见。所以，不论是什么形态的产品、门户端还是中后端，在做系统和功能设计时，迭代的思维同时运用到数据设计上，如先期设计将数据落在产品库中，上线之初可以请技术伙伴人工定期给导出业务数据提供给运营或自己分析，后期设计后台界面给运营伙伴做常态化的数据分析。再如，先期为运营设计数据表格收集用户意见、后期设计运营后台界面给运营伙伴做数据录入和管理。
posted on 2016-05-29 00:47
cheng 阅读(1157)
评论(0) 编辑 收藏 所属分类:
互联网产品