周末闲来无事，突发奇想，打算把自己做产品设计的心得记录下来，写一写自己在产品设计这个职业上的成长。

因为入行没多久，水平有限，一些观点不一定对，欢迎指正交流。

第一篇，就聊一下做方案设计时常踩的坑吧。

1、网络状况

网络状况良好时页面显示一般没问题，但是弱网环境下，页面一般显示不正常，设计方案时需要考虑弱网下，页面中可能出现的情况和相应的提示、展示样式，对于弱网情况的产品技术方案优化，必要时可以作为单独一个需求进行；另外，没有网络时打开页面，页面应该有相应的提示和引导，针对iOS10以及之后的系统，需要考虑网络权限弹窗没出来时的引导方案

2、极端情况的考虑

设计方案，除了常规思维下的用户路径，还需要多想想极端情况下的处理，因为这些极端情况也是需要考虑并告知技术怎么处理

3、并发情况的考虑

对于用户量很大的页面，某个按钮或者功能很容易出现多个用户同时点击的情况，最常见的就是抢购，流量巨大造成的技术上崩溃的情况这里不讨论，这里只说产品上各个场景的交互，比如只剩最后一件物品且无法补货，两个用户同时点击按钮，这个时候如何判断谁先有效点击、没抢到的用户该如何提示等都需要考虑。说到这个，我想到最近的春节抢票，看到一组数据，说春运期间12306每天平均pv达到556亿，每秒访问峰值164w，这个并发的处理，要求真高。

4、方案的时间把控

设计一个方案，要给各个阶段留出充足的时间，以免因为时间不足导致结果达不到预期甚至出现严重bug。一般的流程方案是提出idea，和leader讨论，通过后完善方案，进入产品内部评审，然后拉上UE/UI/NATIVE/FE/后端等项目涉及到的部门评审，ui进入设计，拿到设计图后rd进入开发，联调，提测，qa测试，灰度上线，全量上线，大团队一般还有UE，是在UI进入设计前介入，优化方案交互的。这个过程中涉及到的每一个部门都需要时间，产品在最初构思这个方案的时候就要考虑到涉及到的部门，每个部门大约需要多长时间，同时整体上还要留出一两天的空闲时间，以免发生意外，比如bug过多、更高优先级项目插队等情况，保证项目及时准确上线

5、空白情况

设计一个功能或者页面，不仅要想到页面或者功能在有内容时的场景，还要考虑没有内容进行展示时的空白场景，以文章评论为例子，有评论时按照规则展示评论内容，但是没有评论时需要给出占位图和文案

6、兼容性

目前两大主流系统iOS和安卓，iOS从7到11，安卓从5到8，每个大的系统版本更新都会存在兼容性的问题，同时APP中常常会使用第三方插件，这些插件就很可能因为没有及时更新等原因出现兼容性问题，进而导致APP出bug。虽然这个方面主要是技术考虑，但是作为产品，还是要通过查资料、逛产品论坛等渠道大概知道各大系统有哪些常见的坑，技术评审时也多和rd确认下是否有兼容性等方面的问题

7、沟通问题

产品开发过程中，意外在所难免，产品需要对意外情况及时作出反应和评估，能解决且不影响开发进度的就赶紧解决，同时有必要上报的（如delay、需求开发卡住、优先级pk等）要第一时间上报，和leader保持及时的沟通，不能自以为hold住，自以为能解决就懒得和leader沟通，结果快到约定时间了才告知leader出问题了。一旦最终不能准时高质量上线，锅是你的先不说，项目搞砸对自己影响也挺大

8、试着学习从技术层面考虑方案

个人觉得之所以评审时pm常被rd对到哑口无言，其中一个原因就是技术考虑的是这个方案需要用到哪些接口，会出现什么情况，开发需要多长时间，而产品在这方面考虑的少，所以了解一些基本的技术常识也是有必要滴

9、从全局把握

去做一件事，最初pm都会定一个目标，那么在设计方案时，纠结完细节后，就要从全局考虑，整体上的方案是否有益于完成最初的目标，常见的就是在做方案数据预期时，算到最后，会再从普通用户的思维、常识等方面去考虑这个数据是否合理，这样分别从细节（用户体验，转化率等）和全局（是否符合常识、是否有助于目标等）考虑，能让方案更合理，完成目标的可能性更大。

ps：因为这个职业习惯，我在看电视剧时就会这样去分析剧情，然后发现不少剧都是逻辑混乱，从细节上看，事件A没啥大问题，事件B也没啥大问题，事件A和事件B的衔接也还能接受，但是从整体上看，会发现整部剧的发展逻辑很别扭，进而发现追了很长时间的剧，不知道它到底想讲什么、想表达什么，比如最近看的琅琊榜2。

10、不要相信任何人→_→

作为一个产品，在项目开发的过程中，可能接触到的部门有客户端、FE、UI/UE、QA、后端/服务器等，不管是哪个部门的承诺，都不要完全相信，任何一个环节都需要产品亲自！认真的！确认，你就当成每个环节都会出问题，一个一个去跟进，别寄托其他部门的同事能万无一失，只要你不去盯着的地方，很有可能出问题，比如之前遇到过的，开发说自测完了，结果你一去看，一大堆低级bug，比如qa说测完了、也review代码了，结果你一去看，某条正常路径都走不通。没有时刻盯着进度和结果，一出错，整个团队都是手忙脚乱、心累。

在这里，结合自身经历，我总结了3条规律，简称“微琥定律”：

微琥定律1：项目周期总是比评审时确定的时间要长

微琥定律2：如果pm担心即将上线的项目会出bug，那么它很有可能就是会出问题

微琥定律3：bug总是会让老板遇到，并且只有老板会遇到

11、注意考虑安卓的返回键和iOS的“返回”

从事安卓端方案设计时，要考虑返回键这个因素，方案是否允许使用返回键，在某些情况下是否有必要禁掉，是否对目前的方案中的某一步有影响；另外，iOS没有返回键，那么假如方案中存在加载这个行为，那么在加载的过程中，就要考虑是否允许用户点击左上角的返回按钮，避免因为APP卡在这个页面不能操作，给用户带来不好的体验。

12、版本更新

最近发现几个提高软件更新率的办法，

安卓：除了启动软件时自动检测新版、软件自推送以外，前些天发现应用宝等应用市场可以帮助提高软件更新率，比如软件更新后，应用宝会给用户一个通知，这个可以和应用宝、360助手等第三方或者系统自带的应用市场沟通，应该可以花点money（也可能是免费）搞定

iOS：iOS的软件更新速度，一般来说是安卓的两倍，比如之前负责的软件，新版上线后，一周内，iOS用户更新到新版本的比例大概是70%，安卓需要两周甚至更长才能达到这个水平。最近看到个别APP如果有新版本了，会走一个push，要你去更新，这个在做软件新版本占用率时可以借鉴