摘要：在当今快速迭代的互联网产品领域，社交App作为用户日常生活中不可或缺的一部分，其设计细节和用户体验至关重要。本文作者凭借多年的产品设计经验，从产品经理的视角出发，总结了27条关于社交App项目的产品设计经验。

在当今快速迭代的互联网产品领域，社交App作为用户日常生活中不可或缺的一部分，其设计细节和用户体验至关重要。本文作者凭借多年的产品设计经验，从产品经理的视角出发，总结了27条关于社交App项目的产品设计经验。

产品经理常常很快就把原型画出完了，但是在设计UI的时候或开发的时候就常常被拉去澄清细节。

原因就是对设计的细节交代不清楚，或者了解的不甚深入，缺少对边界或排他项的界定。

笔者将社交App项目做下来后，整理如下见解。

本文就移动端App产品的日常总结，从产品经理设计需求的角度，分享一些注意事项和细节如下。欢迎批评探讨。

从定义需求的角度来说，产品经理只要交代了哪里是按钮就可以了，可以通篇一律使用同一个按钮线框表达。

但是这只能是个初稿，在落实之前，产品经理或交互设计师需要确定按钮的具体形态。

一般而言，一个APP的按钮设定四种就够了，设置的维度可以是按钮的定位权重。（注意，菜单的入口或图表不包括在本次讨论中，比如微信的+、定位图标这种）。

在输出的需求文档中，可以一开始在“全局规范”中就定义这四种按钮代号，然后在原型中备注按钮类型的代号。

这样设计就知道你是要怎么样的效果了。

社交类App登录方式，基本都是手机验证码为主，配合第三方登陆，很少注册账号密码（与App的定位和用户群有关）。

第三方登录就是借助第三方应用的接口实现用户登记，比如常见的三家：微信、QQ、微博。

其目的之一是关联账号，形成社交群落之间的呼应，有利于用户生态链的搭建；其二是获取用户的一部分已有信息，比如用户信息或流量资源。需要注意的有两点：

（1）第三方账号给的资料完善度和安全性不好把控。比如你期望获取QQ中的头像、昵称、年龄、地区，但是QQ可能只给你头像和昵称。

又比如有一天第三方封了接口，那么第三方登录功能就停摆了。

（2）第三方登录方式，对用户来说不一定就是省时省力的渠道。因为相关法规的要求很多APP是需要用户手机号的，而第三方登录并不能获取用户已经提供给第三方的手机号（用户隐私）。

因此对用户来说常常是使用第三方登录后，仍然要跳转到验证手机号的界面，还不如直接使用手机验证登录。

支付很常见，社交应用的虚拟礼物购买、知识平台的付费学习等。在设计支付功能的时候，主要注意的是要从安卓和IOS两个系统的角度区分设计。

（1）首先明确一个常识，就是支付必须是有资质的支付平台才能进行操作处理。

这就是为什么很多大的电商公司的交易要经过支付公司的结算才能拿到钱，比如paypal、腾付通、支付宝、微信支付、网银在线等。其中安卓手机最常用的是支付宝或者微信。

（2）安卓系统接通第三方支付体系还是比较友好的，手续费也不高。调用支付宝或微信支付，会返回其绑定的银行卡或者余额，可以作为业务数据保存在后台。

有时候前端感受不到这个数据，产品经理应该知道，作为功能扩展的考虑因素。

（3）苹果手机（IOS系统）正常来说只能调用苹果支付，苹果顺带扣的手续费比较高。

虚拟支付的时候，安卓是可以使用任意金额充值的，但是苹果手机对特定的原币，只能选择固定的金额。

这个是因为苹果公司将充值金额本身固定了，当成一个一个的商品对外出售。

如下图就是苹果提供的清单，比如可以购买的价格列就是需要支付的金额，收入列就是扣掉手续费之后有效的金额。可以看到花6元钱，在苹果这里只剩下了4.12元。

这就是为什么陌陌同样是充值6块钱，安卓系统给60个虚拟币，苹果只给42个币。

做APP的不仅要盯住页面和用户，也要理解数据的运作，这样对内容推送机制、数据搜索的页面展示的方案选型帮助很大。这里介绍三点：

（1）初创公司的数据基本都使用的云端存储，同时配合自己的数据库。从效率和安全性上都会更有保障。产品经理需大概了解数据存储的定位。

以视频直播类为例，直播或视频数据文件占存比较大，一般都是存储在云端的，而用户业务数据放在自己的服务器的数据库中，原因很简单这些牵扯更多的隐私和安全责任，且一般数据不会太多。

（2）产品经理需直观地理解关系型数据库和非关系型数据库。比如非关系型的mongdb数据库，一般存储信息量大的不定型数据，比如用户日志。而MySQL则承担了大部分可以用二维表表达的规则的数据，比如用户资料、数据字典的参数配置等。

（3）数据存储与页面的搜索方式等方面都有很大关系。比如，在“我的好友”中搜索用户昵称，是只搜索自己关系为好友的用户，还是搜出有一部分是好友，另一部分非好友的用户并用标签分类呢？

这两个方案前者比较保守，但是如果期望用户扩大社交圈的话后者更有价值。因为不仅可以看到好友并且还能提供增加陌生人为好友的功能。

但是这时候还要结合后台数据的存储，是否好友和陌生人存储在一个表里了呢，如果分开了那最好就不要一起搜索，随着用户量增大，聊表查询很耗性能。

项目过程中，前端与后端开发之间沟通需求基本都是围绕接口请求数据进行的。接口是前后端分开开发的行业标配吗，是高内聚的体现。

因此产品经理要理解接口的原理和自己的目的，协助前后端完善接口的定义（另一篇文章有专门介绍）。

后端开发在写接口的时候，一般需要知道未来的走向，包括数据量级、功能扩展性等。

产品经理要针对该功能给开发们说清楚未来的扩展可能性。比如：App的用户动态的评论，计划是展示一部分优质评论内容（类似微信的朋友圈）在外层，类似下图：

但是对于展开部分的算法尚还在研究阶段，因此这个版本将评论折叠，只显示数字。点开则打开评论列表。

后端在给前端传的接口中，可能会多设计出“是否展示在外层”标识，提前预留参数，以后版本用。本版本前端只需填留下自己需要的信息即可。

App用到图片的地方很多，每一处又可能有不同状态下的不同表现形式。产品经理不能只放一张图了事。应当对图片不同场景下的样式列举清楚。比如下面几点：

微信朋友圈的列表中，图片都是缩略的。那么设计的时候首先就是缩略方式的问题。

之所以要给出缩小的比例或最终尺寸大小，是因为拍摄的手机屏幕尺寸和比例不一致，上传的图片又可能有各种形状。

因此发布之后要给予对应的规则和秩序。避免效果模糊、展示不全、图片过小等不良效果。

在确定方案的时候，合理即可。可以通过研究竞品，找近期流行的产品的规律。比如：

按图片或视频的H:W:

①H:W>4/3(高图）：切上下两端，保存为4/3，靠左展示。

②3/4≤(H:W)

③H:W≤3/4(扁图）：切成3/4，靠中间展示。

以上并不一定是最好的，但是秩序是要给到开发的。

留意的话，就会发现有的App的图片是圆角的有的是直角的。

目的只有一个，就是确定这两种展示方式哪种更符合产品的定位和气质。

一般而言，做社交类的产品，图片用圆角看着舒服和气。做技术类的或者法律类的比较严肃的产品，可以考虑直角。

最后还是一句话，看竞品，以及一段时间流行哪种。

消息发送成功之后 ，图片也是缩略的。并且要设计发送失败的提示图例。点击打开之后大图是否铺满整个窗口？

最后就是不要忘记做缩略图和大图，这是完整的一套。

另外在很多公司，这个算是设计师方面的工作，但是产品经理要全局把关，就要知其然知其所以然，不是主管觉得看着顺眼就这样吧。

产品经理在设计拍摄视频或图片功能的时候，需要考虑是否满屏拍摄，是否限制必须按一定比例拍摄等。

之所以考虑这个问题，是因为有的手机全屏比例拍摄的效果并不美观。另外一些带刘海的手机屏幕，刘海部位必然是看不到拍摄画面的。

因此为了避免这个影响，很多产品就会选择将上方平齐与刘海的高度遮住，设置成只支持刘海以下拍摄。

当然，也有将底部菜单位置遮住的，还有的规则是只允许拍摄出指定比例的画面，比如安宽度固定，取16:9的画面作为视频窗口，多余的部分在拍摄期间都用黑色背景遮住。

这种规则的制定有好有坏，属于A/B选择的问题。这个选择，需要产品经理来定。

产品经理可以通过借鉴竞品和分析本产品的定位，有理有据地说出自己的理由，支持自己的观点即可。

以拍摄视频后的贴纸为例，贴纸可以贴在视频的指定位置，也可以应用在视频的某一时间段上。

但是根据调研，多数用户使用的功能只是选择贴纸、删除贴纸和拖动位置。少数用户才会花精力在手机上调整贴纸应用的时间段，因为这个操作稍微有点麻烦。

但是毕竟还是有这么一小部分用户是希望将自己拍摄的作品精益求精的，对此我们看如下方案：

方案一，在选择贴纸的同时就展示出时间轴，让用户选择贴纸和应用的时间轴一次性完成。让功能集中在一处开始和结束，干净利索。

方案二，将选择贴纸、删除贴纸和拖动位置放在第一层。完成之后，再点击该贴纸，弹出‘编辑’，这才进入时间轴的编辑。

很明显第二个方案要好一些，一来提高了大部分用户的操作效率，不被无关的功能干扰；另外也不会影响发烧用户进一步挖掘极致。

这其实是整个产品设计的指导思想：考虑了复杂性和使用频率，针对大众用户和极致用户进行功能分离，最终实现完美的效果。

图片上传是APP离不开的功能，比如聊天消息、上传照片做认证或头像等。

提到图片上传，就离不开上传的规制、发送或上传成功的效果、点击后的效果、发布失败的效果、下载到本地的效果等。具体可以这样分析：

（1）上传的图片文件大小和尺寸大小的要求：

在服务器承受的压力之内尽量不做限制，必要的时候才给予阈值。作为产品经理，需要与开发沟通当前的方案选项是否有限制的必要。

一般而言，可以由客户端自行压缩或调整后展示。

对于PRD，给不给上述限制都要交代清楚。

（2）限制一次上传的图片张数：

比如微信是9张，抖音12张。对于PRD，该限制虽小，但要交代清楚。

（3）上传的图片限制格式：

一般尽量不限制。作为产品经理，需要与开发沟通当前的方案选项是否有限制的必要。对于PRD，要交代清楚。

（4）上传图片后展示的效果：

一般都是缩略图，固定显示的长宽高。上传失败的图片，支持再次上传。

点击上传成功的图片，打开大图。

（5）若需要该图片进行小图标或者展示形式的多样化应用，则后台只需要保存原图，其余的格式化应用在客户端进行定义。

比如头像图片在后台存一张大图，应用层面展示的是原型图。又比如送礼物的图标，选择的界面展示的是大图，发出去之后的消息通知可能就只是个小图标。

（6）图片上传的方式：

①第一种是九宫格式的

典型的就是微信发朋友圈的图片上传功能，这种图片上传功能适合上传多张图片，图片的呈现方式一般都是九宫格的方式，在社交类，电商类的商品上传和写游记的app上多见。

多用于信息内容的展示，一般都是图文相结合。一般是先开启相册选取图片，图片的点击顺序也一般是最后的呈现顺序。

②第二种文件上传式

一般在聊天界面会用到这个功能居多，点击qq和微信下方工具栏的加号都会有一个图片上传的功能，这种功能一般是基于聊天的场景，这部分图片上传功能展开的方式都是半浮窗的样式，系统会先展示当前相册最近的几张图片，会有选择是否发原图的设计。

③第三种嵌入式图片上传

嵌入式图片上传一般应用在文档撰写类的应用，在编写文章的时候需要嵌入一些图片说明，这种设计时图片嵌入属于一种辅助文档编辑的功能，一般需要去调取系统相册，然后手动从相册里选取出你所需要的图片，可一次性上传多张图片。

④第四种添加附件

这种图片上传形式一般图片会作为附件的形式上传，也是调取系统相册，一般上传成功后图片都是缩略图的形式展示。

例如我们常用的写周报和百度云盘里就常用到这个功能。这种设计的图片上传功能适合大批量的图片上传。

时间的显示基本分两类，一类是展示在外层的，不需要很精准的时间，比如聊天环境下的时间、用户动态外层显示的时间；另一种作为严格的时间落款，比如账单明细。

后者基本可以一刀切，就用年月日时分秒，一般都不是问题。

前者就要切合场景，对时间的要求和用户情感的匹配性，融入一定的感情色彩或者暗示。这里就有多种流派，比如推特和微信就区别很大。

对于前者，笔者在这里整理一套自己用于聊天信息、评论、系统消息、动态的时间的展示规则，可以作为借鉴：

刚刚（T

XX分钟前（1≤T

XX小时前（1h≤T

昨天 +点钟（24h≤T

日期+点钟（48h≤T

年-月（1年≤T） 比如：2018-5

用户如果未开启APP的设备授权，那么用到相应的功能，就需要临时提醒用户授权。

比如点击【抖音】的拍摄按钮进行视频拍摄，就需要请求摄像机授权。

如上图，点击“去设置”，则前往手机的【系统设置】界面手动操作。

相当于App只负责告诉用户：我需要你去设置中授权。

①若不同意，则放弃视频功能的使用。

②若同意，则前往【系统设置】中，执行独立于App之外的操作。

操作完成，会发现连个返回APP功能都没有，还需要自己找到App再进入一次。是不是很low？

为什么不能在App中一键完成授权呢？

这其实与手机操作系统有关系。

以IOS为例，手机操作系统对设备授权有一个规定：

安装后，首次打开App，App会自动请求用户进行设备授权。

仅此一下，之后打开App，操作系统就不会帮忙请求了。

因此，若首次未授权，或之后关闭了授权，那么手机系统不允许App直接一键授权了。

明白这个道理，设就可以设计出贴合实际的方案。需摸到操作系统的“屋檐”，适当“低头”。

刷新，是产品经理需要定义的常见的功能。

要么是手动触发刷新，要么是定时任务触发。

定时任务触发，比如1分钟内的消息显示“刚刚”，那么系统就可以每一分钟自动刷新一次，使显示合理的时间格式。

本文主要以手动触发说明，产品经理至少可以考虑四个方面的问题：

列表页面加载，主流触发方式是滑动，包括上下左右滑动。

对于瀑布流的内容为主的产品，刷新较为频繁，除了使用滑动加载之外，还可配合按钮加载。

比如【抖音】，可以双击底部菜单实现页面刷新。

“滑动+点击”这样的设计，避免用户置身于视频瀑布流中只靠单一滑动带来的枯燥和不适。

刷新有打开新页面的，也有在当前页面加载新内容。

打开新页面的，需要考虑如下：

a. 翻页方向：目前流行的交互方式，是左右平移或覆盖平移，比较符合用户对线性操作流程的的直观感受。

b. 加载发生在翻页的前还是后呢？

翻页前加载：适用于需要判断及验证处理的页面中。例如表单信息判断和登录验证等。

而绝大部分app采用翻过去之后加载，这样可以极大的增强页面的流畅感。

a.loading标示的样式

菊花和进度条是最基础的loading标示。

若做成动画，或者加入App品牌特色，就更显诚意了。

b.loading标示的位置

是在顶部、中部、还是底部呢？

若看不出优劣，就选一种，并向团队交代清楚。必要的时候做A/B测试。

在实现机制上，产品经理要说清楚效果。

比如最迟不超过2s、要求某些内容先加载出来等等。

这样就引导出了常见的几种机制：

异步加载、分模块加载、懒加载和预加载等。

需要注意的是：加载机制不仅仅是受限于网速，更是信息泛滥时代的一种策略：

让用户优先看到什么，节约用户精力，提高回报率。

在设计消息菜单的时候，需要考虑默认置顶、消息归类等功能。让目标信息曝光增加，同时让消息有条理。

比如，【互动通知】置顶在列表的最上方，类于“文件夹”。点击，则打开系统消息列表。

一般而言，人与人的聊天显示未读条数，因为时效性要求高。

超过99条一般显示99+。

实际显示99也可以，对用户而言已无差异。

非紧急的通知可以不显示具体数字。

消息已读的判断标准：只要打开就算已读。

哪怕眼前条只展出了1条，哪怕没来得及看就手机掉线了，也都当做已读处理。

分两类，一类是单条聊天记录的删除；一类是整个聊天条目的删除。

可以保存在服务器，用户可以通过加载，分批查看历史消息。

此外，考虑聊天消息的复制、转发、失败重发等。

产品官网，初期都很简单，基本都是：产品介绍+下载链接。

功能不复杂，因此可以考虑设置手机访问官网的功能。

如上图所示，手机端直接访问PC官网体验极差。

因此需要一定程度的适配，大概会有以下几种形式：

①极简适配

极简适配就是对内容进行删减，直到剩下最后一个页面，用一个页面去呈现最基本的产品介绍以及下载按钮。

②完全适配

做了全适配的官网会在手机端有良好的表现。当然，Pc端的官网有时候体量太大，在适配到手机端的时候也要有删减。

很多App的Tab页签，支持左右滑动切换。那么是不是在设计Tab页签的时候都要这样规划呢？

笔者认为在确定这个方案时，产品经理需要考虑如下：

（1）明确滑动切换页签的优缺点

操作步骤上，点击切换和滑动切换都是1个动作事件。只是通常来看，滑动操作比点击操作难度稍低，毕竟点击需要找到触发区。

另一个方面，支持滑动切换可以覆盖更多用户的操作预期——假设用户普遍习惯滑动切换的操作方式。

但是滑动切换页签的操作本身也有弊端。比如有时候本来是想上下滑动的，但是手指一不小心就滑歪了，于是无意识触发了滑动事件，跳到了另一个页面去，可能就打断用户沉浸式体验。

（2）基于以上，笔者建议如下

①沉浸式的瀑布流，比如抖音的视频流，不推荐滑切Tab页。

如果非要做，则将滑动切换触发灵敏度降低。

②内容长度有限，或者阅读速度快的Tab页签，可以使用滑切。比如电商商品的【参数】、之间的切换。

来源：人人都是产品经理一点号