2.2 基本概念

2.2.1 “入口”的概念

以我的经验总结，入口的概念一定是每个跟你谈需求的产品经理或运营心目中十分在意的产品要素。产品所在的位置以及触达用户的途径就是入口。入口有几个层次，有页面层级的入口、应用层级的入口、操作系统层级的入口、终端层级的入口如图1-2-1所示。

图1-2-1 入口的层级关系

一个应用内部，入口在“首页”及“首屏”就是顶级入口，因为它会吸收最大的主动流量。进入其他分页（Tab页）或下一层级页面或下一屏页面，其入口流量一般都会衰减。设计师需要具备“首屏”的意识，尤其在设计例如有唯一操作的表单页（操作按钮应该保证在一屏内展示）、内容类型诸多的内容分发页（最重要的模块保证能在首屏展示，如果不行就要提供往下滚屏的预期）。另外，入口的流量大小存在差异性，一般一个大的流量入口可以为同一页面中其他小的流量入口带来转化。“朋友圈”入口在微信的第三个Tab，是为了给同一页其他小工具带来用户。

应用间可以相互成为的入口，这个理念在腾讯相关应用中被运用到了极致。微信就是一个最大的流量入口，它搭载了腾讯新闻、腾讯视频、腾讯游戏等内部来源的内容，同时为这些应用带来流量转化。

主流手机系统中设计了桌面应用图标、通知栏（Notification）、桌面小部件（Widget），还有iOS特有的3D Touch触发的快捷操作菜单等构成了独立应用不同深浅程度的入口。产品的触达需要以立体时空的视角去规划，而不仅仅着眼于打开应用看到的这一层界面。iOS的3D Touch的诞生就是系统为产品提供了一个离用户更近的触达方式。有别于通知栏的状态异动的提醒，3D Touch旨在提供场景化的快捷功能入口。

脱离移动产品形态而言，手机就只是一个非常普及的“入口”而已，很多前沿的科技公司还在争夺下一代可能替代手机的服务入口，例如智能路由器、智能音箱、手环、智能手表、智能眼镜、智能电视、智能冰箱，等等。

入口越前置，一般意味着越容易触达到用户。入口深度之所以重要，其根本原因取决于人的本性是懒惰的，注意力是容易被打断的，精力是有限的。所以一个人机交互系统需要有主动进入和被动引入的不同层次的入口。“入口”的设计有以下一些基本原则，决定了产品的基础体验。

入口唯一性：一个完善的产品体系下，每个主功能的入口都应该保持唯一性。不宜在不同定义的页面下重复出现入口。虽然说布置多个入口意味着多个流量来源，但极其容易混淆用户的认知心智，也说明产品没有梳理足够清晰的信息架构。

入口稳定性：若入口不稳定，可想而知用户会不断改变业已建立的使用习惯。在规划产品架构时，应该充分考虑到产品当前、中长期甚至终局的方向，保持架构的可成长性。

入口的场景特性：设计合理的入口位置，不会让用户猜测自己需要的某个功能可能在什么位置，更不能与一般常识相违背。在应用主入口之外，另外还有一些入口负责引导用户进入，位置往往比主入口更前置。设置前置的入口，往往意味着要设计“场景”。设计场景时要创造动机，利用好人性中害怕损失、偏好意外收获的心理，可以更好地提升入口转化。

2.2.2 “层”的概念

应用除了“入口”，还有一个重要的“层”的概念。“入口”是一个具体的存在，而这里所谓的“层”则是一种意识化的概念，比较抽象，你可以理解为因为某种原因在产品流程中形成了组块与组块之间互不相融的人为分隔。我在这里尝试用不同维度区隔的层来加以阐释这个概念。

产品区隔的层，可以理解为交叉调用不同产品封装能力所形成的人为分隔。比如在一个认购理财产品的应用中，因为个人账户认证的需要，临时跳转到身份认证的封装流程中，待完成后又重新跳回原流程继续完成理财产品认购。又如在一笔完成支付的流程中，要先跳出支付步骤去完成一次绑卡的封装流程。从架构设计的角度，不同的产品需要聚焦在自身的功能价值上，而同时又不可避免地牵扯到相关的产品能力，解耦各个能力是比较理想的设计方式。在设计时，你可能需要关注这些层与层之间的信息承接问题，比如要向用户透露跳出的原因，以及上一层结果如何带入下一层，等等。

体验区隔的层，也是不太容易被关注到的设计意识。在流程中，常见一个页面内的动作点会跳出到一个小分支，这个分支流程还会有同样的动作点进入相同的分支流程，如此无限循环。这种设计模式很有可能发生在从批量信息跳转到单个详情，又有机会从单个详情关联到新的批量信息。这个批量信息中必然可以跳转到单个详情，而单个详情内又带有跳转到批量信息的入口……不加设计干预，带来的问题是，当用户返回时，是否要经历之前所跳转的所有步骤。真的要走漫漫不归路吗？程序逻辑上有一个堆栈的概念，堆栈可以叠加也可以替换。因此在设计上应该树立“层”的区隔。以批量信息页为起点，单个详情为终点设定成一个闭环的层。每次起跳一个新的批量信息页，都定义为刷新替换上一个层，进入新的循环。这样返回会变得干净利落，用户不至于再无休止地回溯自己已经不关心的浏览历史了。

技术区隔的层，实质上会要求设计师对技术实现有基本的理解和预判。比如，在某个步骤中，需要RPC（Remote Procedure Call）向服务器远程调用一些校验结果或数据反馈；而有些逻辑只需要客户端本地实时判断反馈结果。对应的设计处理方式就会不同。例如，你在设计一个发送红包的流程时，填写金额大小是否超限可以通过输入框的写操作行为实时判断，而是否有足够的余额或是否超出了当天的发送限额都需要在发送的当下请求服务端做最后的校验。这就需要设计区分判断时机和反馈触发的方式。再如，在开发的逻辑定义中，某些步骤是非必现流程，只在特定情况下出现，此时你就要考虑把这部分切割出来，不要把它和其他页面糅合在一起。例如在登录时，假设短信验证码是在输入账号和密码后特殊的安全校验步骤，那就建议把短信校验这一步单独成页。