这篇文章是基于我过去几年开发工具类App的经验总结，主要探讨在搭建App 1.0版本时需要重视的全局设计问题。内容较为基础，适合经验尚浅的产品经理（PM）参考，资深从业者可以直接跳过。

在开发App 1.0版本时，项目团队通常会优先推进功能开发，以控制成本并尽快达成关键里程碑，这往往导致用户体验的优先级被相对忽视。如果产品经理经验不足，一味地赶进度、堆功能，很容易忽略App的整体体验设计，从而为后续的项目迭代埋下隐患。另一方面，如果在设计阶段没有充分考虑基础体验，研发人员在开发过程中可能会频繁提出疑问，甚至需要返工修改，反而降低了开发效率，延长了项目周期。

我自己曾经在两天内完成了两个App 1.0版本的原型设计和需求文档，总体感受是：设计功能简单的初期版本并不难，真正的挑战在于如何在紧张的工期下保证App的整体体验。

以下内容主要以iOS的交互设计为例展开，安卓的设计可以根据Material Design的原则进行调整，或者直接与iOS共用一套设计。

1.错误提示 

对于重复性较高的业务流程，系统运行过程中出现错误的概率也会相应增加。从用户体验的角度出发，我们不能将所有错误都直接展示给用户。即使是必须告知用户的错误，也应该尽量以更友好的方式呈现。

除了业务逻辑相关的错误，移动端通常只需要向用户展示两类错误：网络错误和服务器错误。有些同学可能认为，多数用户并不理解什么是服务器错误，而且在成熟公司和项目中，服务器故障导致前端无法访问的情况并不多见，因此干脆省略这类错误提示。但个人认为，这两类错误还是应该区分开来，因为一旦用户、运营人员或客服反馈问题时，能够快速定位是哪一类错误，从而提高问题解决效率。

网络错误和服务器错误又可以根据操作场景进一步细分：整页加载时报错、局部加载时报错以及点击按钮时报错。其中，整页加载报错和点击按钮报错容易理解，而局部加载报错主要指的是上拉加载更多内容时出现的错误。对于整页加载出错的情况，通常需要设计一个单独的提示页面；而对于局部加载报错和点击按钮请求服务时出错，一般可以通过Toast提示或弹窗提示来解决。

2.空页面 

在使用App的过程中，用户可能会遇到页面内没有数据或者页面加载出错的情况。这种情况下，页面需要展示“空状态”，以明确告知用户当前页面为何为空，以及用户接下来可以采取什么操作。

空状态分为整页为空和局部为空两种类型。虽然它们出现的位置不同，但在处理方式上可以采用相同的策略。

空状态的提示通常由以下几部分组成：图片、提示标题、提示文案和操作按钮。如何根据实际需求对这些元素进行组合搭配，最好在App的1.0版本设计阶段就确定下来。虽然在项目后期也可以添加新的版式设计，但对于开发人员来说，他们可能在前期已经开发了几种通用版式。如果临时需要添加新的设计，就需要看你的沟通能力和开发团队的配合程度了。

常见的有以下几种情况：

3.页面内刷新/加载 

对于页面内容较少的情况，可以直接一次性加载全部数据；而当内容较多需要分页时，则必须明确每次加载的数据条数。

在页面整体加载时，通常会在页面中部使用加载动画搭配提示文案。对于下拉刷新和上拉加载更多功能，则分别在页面顶部和底部添加相应的提示信息。当用户滑动到页面底部且没有更多内容时，还可以增加一个额外的提示，例如支付宝中的“我是有底线的”这种友好提示。

此外，现在很多App在加载过程中会使用带有品牌标识的GIF图来增强用户体验。不过，在App的1.0版本中可以暂时不考虑这一细节。只要设计了全局加载机制并让开发人员完成了开发，GIF图可以在后期再进行替换和优化。

4.切换页面的刷新/加载原则 

页面的整体刷新可能会干扰用户的锚点定位。

例如，当用户拖动页面中的列表滚动到中部某处时，如果此时切换到其他页面，再返回原页面时页面发生了刷新，那么用户将被重新定位到页面顶部。此时，用户需要再次拖动页面才能回到之前浏览的位置，这种体验在某些情况下是非常糟糕的。因此，我们需要明确界定各个页面之间跳转时是否需要刷新。

以下提供一个参考思路，既可以作为整个App的通用规则，也可以根据具体场景灵活调整。

5.弹窗 

在App中，弹窗样式也是可以复用的。有经验的客户端RD会把弹窗做成global，这样一旦需要在大版本迭代中对弹窗UI样式进行修改时，只改动global里的设计就能完成App里大部分的弹窗样式。

所以基于这点考虑，在1.0版本时可以把后期可能会用到的所有弹窗样式都列举出来给RD；各种样式说到底是图片、标题、说明文案、输入交互和按钮的组合。

常见的弹窗样式见下方，其中没有交互（输入项）的dialog会在App中占大头，其余的也可以让RD在项目过程中遇到时再做特殊处理。

6.操作面板 

屏幕底部弹出的操作面板本质上是另一种弹窗，事实上有很多同样的功能在不同的App上有用弹窗实现的也有用操作面板实现的（至于从开发的角度看是否一样，本汪就不知道了）。

这里且不说复制的操作面板——因为一旦功能复杂肯定是要做特殊处理的——就说最常见的多选功能的操作面板，样式如下：

需要注意的是

对于开发人员（RD）来说，带有说明标题的面板和不带说明标题的面板是两个不同的组件，需要进行区分处理。

7.升级引导 

最后来谈谈App的升级引导问题。项目团队辛苦开发出App并发布了第一个版本，用户量逐渐上升，但在后台却看到了各种吐槽。于是团队急忙迭代开发出第二个版本，却发现第一个版本没有设计升级引导功能，这简直让人崩溃！

因此，我建议：只要准备发布App，就必须设计升级机制，否则即使客户不更新，产品经理（PM）和开发人员（RD）也只能干着急。

升级通常分为强制升级和可选升级两种类型。

对于安卓平台，由于各个应用市场相对宽松，可以在发布新版本时，让App直接在本地（通常是在WiFi环境下）下载新的APK文件，然后再询问用户是否要升级；或者先询问用户是否升级，再由用户决定是否下载。

而苹果App Store的情况大家都知道，对开发者的约束比较严格，不允许开发者直接引导用户下载更新。如果将升级提示逻辑直接嵌入IPA包中，并且在审核时被检测到，苹果是不会允许上架的。因此，只能通过后台控制来绕开这个限制：

1. 升级提示逻辑不能写在本地；
2. 先发包审核，通过审核后再由服务端控制，在客户端弹窗引导升级。

八、其它 

以上所述的基本上都是产品设计层面的基础搭建。除了这些之外还有缓存机制、crash收集、日志记录、定位机制、消息推送、埋点等需要考虑，以上每一项单拿出来都可以写很多，此处不展开，以后视了解的深度情况再分享。

優(yōu)網(wǎng)科技秉承"專業(yè)團隊、品質(zhì)服務(wù)" 的經(jīng)營理念，誠信務(wù)實的服務(wù)了近萬家客戶，成為眾多世界500強、集團和上市公司的長期合作伙伴！

優(yōu)網(wǎng)科技成立于2001年，擅長網(wǎng)站建設(shè)、網(wǎng)站與各類業(yè)務(wù)系統(tǒng)深度整合，致力于提供完善的企業(yè)互聯(lián)網(wǎng)解決方案。優(yōu)網(wǎng)科技提供PC端網(wǎng)站建設(shè)（品牌展示型、官方門戶型、營銷商務(wù)型、電子商務(wù)型、信息門戶型、微信小程序定制開發(fā)、移動端應(yīng)用（手機站、APP開發(fā)）、微信定制開發(fā)（微信官網(wǎng)、微信商城、企業(yè)微信）等一系列互聯(lián)網(wǎng)應(yīng)用服務(wù)。