此文谈不上经验，不足教导他人，产品新人，记录自己半年来摸索产品设计的所得所想，仅此而已
废话不多说，直接上粮食吧
关于产品设计的思路
第一步：明确该需求的目的
包括用户需求和产品目的两个方面
第二步：辨别需求是否可做
1.如果资源有限，就问自己一个问题“如果不加这个功能用户是否就会离开？”
2.如果你还有一些资源可以做一些事情，那你就问自己“各个功能的复杂度如何？这个功能有多少人用？用的频度怎样?能带来什么增加的价值，如：日活、产品丰富度、产品在百度上的搜所排名？增加的价值是否是核心的部分？投入产出比是否值得？”
第三步：明确自己产品的现状以及对手的情况（这一步也往往先与第一步，是一直应该关注的，不应该等到需要做的时候再去调研）
1.竞争对手目前的情况如何？
2.相关数据的情况？
3.功能上线后是否可以跟进相关的运营？（和运营沟通非常有必要，不是产品做完就结束了）
4.预期的产品效果（产品要对功能有一定的预期）
第四步确定需求后对需求进行拆分
第五步原型设计与文档撰写
关于原型设计与文档撰写是建立在前4步基础之上，原型交互要尊重APP整体风格，结构清晰、模块分明、层次协调，且务必在原型出好后在用户使用的关键路径上在脑袋里模拟交互，看流程是否通畅
2.关于文档，每个人的描述风格不一样，只要能描述清 楚，功能点不漏，但是也要尽量避免歧义，如果是去掉的功能，一定一定一定要标注清楚，否则研发真的会做上去，验收时研发就会说，你原型没有可是文档里没写要去掉~~~也是心累
以下是几个写文档时比较容易疏漏的几个点（都是细节~~）
关于键盘的问题
（1）进入某一个页面时，如果主要目的是让用户输入内容，如填写什么信息，键盘需要自动调起，否则的话可以是点击输入框后再自动调取
（2）根据功能的不同，需要规定调起的键盘样式是换行、完成、发送或者搜索，调起中文、英文还是数字，这个研发哥哥是可以做到的
（3）键盘消失的时机，可以是输入框失去焦点的时候，或者上下滑动屏幕等，有些软件会自己做键盘，键盘上有完成按钮，如：香哈菜谱 需要视具体情况而定
关于输入框的问题
（1）需要用户输入多行文字时，根据具体情况判断输入框是否需要自增高
（2）当输入框被键盘覆盖时，屏幕需要自动上滑，始终保持光标紧邻键盘上方
关于触发该功能时用户的状态问题
（1）使用该功能时是否需要用户登录，登录/注册成功后是否有需求记录登录之前的状态需要明确，如：点赞功能，登录成功后如果未点赞直接变成已经点赞等
（2）是否需要用户用户实名制、绑定银行卡、填写地址等等~~~
关于是否需要缓存的问题
缓存问题主要看两点：1.断网或者无网情况下，想要展示给用户什么信息（与该功能的重要程度有一定关系，该功能是核心功能，则最好是缓存，比如豆果美食菜谱是核心，那菜谱会有缓存，一般的列表也会有缓存） 2.考虑缓存会不会使得缓存变得过大（尤其是大Android，如果缓存过多，各种监控软件就会逼逼个没完）
关于是否需要提前预加载的问题
锦上添花，希望用户等待时间较短，优化用户体验，视功能而定
关于是否翻页的问题
如果数据量比较大，一次加载全部会导致服务器压力较大，且用户等待时间较长，要规定首次加载数量和上滑加载时每次加载的数量，可与研发商量看看服务器所能承载的
关于是否需要需要支持该页面的openURL问题
如果对后期的规划有需要或者需要运营配合活动时，一定要注明：该页面支持openURL
关于数据是否需要实时计算
一定要慎重慎重再慎重，实时运算数据会导致运算量比较大~~~研发很生气，后果很严重~~~
关于极端情况
研发大多数考虑的都是议程流程如何处理，所以一定要考虑到异常情况，包括上文所提到的数据为空、数据过多、断网、同一个用户在两个客户端上同时登录怎样、老数据怎么兼容处理（注：不是所有的极端情况都要处理，人比如测试会提出：同一个用户在两个客户端上同时登录进行了***操作怎么处理，这种比较特殊的例子如果对整个功能影响不大且没有资源做的情况下可以暂不处理）
关于文案
要考虑小屏幕适配的问题，尤其是iPhone4和4S
关于分享后页面
要注意品牌的漏出，与用户回流，说白了就是简单粗暴的加二维码
写在后面~~~那些年踩过的坑
先说说评审需要准备的
1.对自己的文档不说能背下来，但是每一个细节都要了解，研发问起的时候要可以回答上，不要想半天 ，信任感会降低
2.对预期效果和数据要有一个大致的预期，研发负责人会在意数据的问题，如果提前没有做好调研，没有数据支撑，会被喷的很惨
3.适当妥协，合作多了之后要大致知道研发在哪里会喷这个方案，评审前就要知道哪些是必须坚持的，坚持的要有理有据使人信服，可以妥协的，满足研发的参与感
4.为了沟通效率，可以在设计的过程中就与UI、研发沟通，评审时沟通起来就会顺畅很多
5.如果评审时吵架比较激烈，评审后可以单独找评审上言辞激烈的几个人单独沟通，为下次评审做好准备，群狼可怕，独狼并不可怕~~一个个收拾，呵呵呵，就是吹个牛逼
再说说h5交互的一些局限
1.一些tab想要做上滑吸顶，慎重，大坑~~~效果极其差，
2.吸底的输入框，慎重，大大的坑，如果对交互效果差的容忍度机会为零，不要考虑，没有解决办法，最好的效果就是吊起键盘时输入框被遮挡，然后在瞬间跳出来，可以多找一些H5的页面试试,看看能不能忍受，折中方案有两种：一种但是单独开一个页面（可能与端内的交互不一致），一种是做成native(开发周期较长，调整不灵活) 可以给出方案老大选择~~~
3.H5的弹层的效果比较差，轻易不要使用
4.H5在端内的分享如果是在导航栏上h5无法获得是第几次分享，如果需要用户分享之后再有后续操作的需要把分享做到页面内：如分享之抽奖，需要把
5.H5实现双击点赞效果比较费劲，双击页面很多会放大页面
6.端内的H5上传图片会存在问题，要确定客户端开发的虚拟浏览器是否开发了该功能，如果仅仅封装了浏览的功能，在端内H5上传会获取不到数据
技术上实现有问题的一些点
1.用IMEI记录一些信息，双卡双待的手机会有两个IMEI~~~而且ios会给一个临时IMEI，卸载重新装之后就IMEI信息会改变，导致之前记录的信息丢失，且不可找回
2.图文混排尤其是图片在文字后方的时候文案不可以从中间截断
大坑未完待续~~~
